最先进的Crypto进入后量子时代(采用容器化TinySSH)

2020-07-26 00:55:34

保密是计算机科学最重要的功能之一。如果电子保密突然崩溃为完全透明,我们将无法从事电子商务,我们将无法私下沟通,我们过去的通信将在全球范围内可见,我们将受到无数方面的严重影响,这将从根本上改变我们的工作和生活能力。想一想我们每天花多少时间用密码、锁模式、无线Fobb和生物识别来维护我们的机密性,这些密码、锁模式和生物识别技术限制了访问以保护我们,以及它们失败的后果。

公钥密码系统构成了我们保密的一个重要方面。通过公共媒体建立私人通信的能力每天被使用数十亿次。如果技术的出现揭开了这种私人话语的面纱,后果可能是不可估量的。

在量子计算领域,这样的技术正在兴起。可以执行肖尔算法直接威胁常用公钥方案(RSA、传统的Diffie-Hellman和椭圆曲线)的潜在硬件可能比我们预期的更接近实现。D-Wave公司承诺今年将交付一台5000量子比特的绝热量子计算机;这台计算机不能直接运行肖尔的算法,但如果运行,TLS和SSH将受到严重威胁。有一些紧迫的事情需要纠正我们的密码系统。

与渗透到我们电子产品中的无处不在的CMOS技术不同,量子逻辑是一种截然不同的设计,它适应了不确定性和不确定性,从量子位的形式开始,这是一个违反直觉的二进制数值,可以同时为正值和负值。这些新的计算设备的威胁是非常真实的,以至于美国国家标准研究所(National Institute Of Standards)发起了一场争夺量子抗性公钥密码系统的比赛。

在这场争论中,TinySSH,一个嵌入焦点的最小SSH服务器,已经实现了一种混合密钥交换,使用NTRU Prime(NIST竞赛的第二轮决赛选手)与传统的ed25519椭圆曲线密钥相结合。该方法允许ed25519密钥通常继续使用,但透明地增加了量子转发保密的外观。";OpenSSH v8.0中采用了该方法:

提交dfd591618cdf2c96727ac0eb65f89cf54af0d97e作者:[email protected]日期:*Mon Jan 21 10:20:12 2019年+0000。上游:添加对PQC KEX/KEM的支持:使用简化的NTRU Prime*4591^761实施,添加对PQC KEX/KEM的支持:[email protected]。默认情况下未启用。

TinySSH服务器严格遵循与Daniel J.Bernstein相关的加密技术,大部分SSH会话流量依赖于chacha20-poly1305;不允许使用其他密码。它同样不允许密码登录,但需要准备好用户ed25519密钥才能成功连接。这些约束可能看起来很僵硬,但它们也是最佳实践。

TinySSH服务器可以补充或替换Linux OpenSSH守护进程,并且提供了通过inetd或systemd套接字激活来执行此操作的说明。TinySSH的极简主义立场也很适合Linux容器设计,但要实现这一点需要做一些调整。

无论如何,NTRU密钥交换已经在OpenSSH中部署了足够长的时间,因此通用是一个合理的目标。它也远比ssh-rsa密钥更可取,ssh-rsa密钥是多年来默认的SSH2用户和主机密钥类型,现在由于对SHA-1的依赖而受到严重削弱。虽然TinySSH的作者Jan MoJžíš暗示,NTRU密钥交换还没有达到可以投入生产使用的地步-包括后量子密码-启用它肯定比继续依赖SSH-RSA更安全。

一般说来,容器共享一个共同的内核,但有不同的用户空间,这将它们与虚拟机区分开来。最直接的Linux容器可能从BusyBox开始。在本练习中,我获得了使用MUSL libc(而不是uclibc)编译的1.31.0版本。选择合适的体系结构;我已经开始使用标准的x86_64 PC。

以本地目录中有BusyBox副本的root用户身份,输入以下命令以组织并启动/home/pqc作为Post-Quantum Container:

#mkdir-p/home/pqc/bin#cp busybox-x86_64/home/pqc/bin#mkdir/home/pqc/root#mkdir/home/pqc/ssh#mkdir-p/home/pqc/var/log#cd/home/pqc/bin#chmod 755 busybox-x86_64#./busybox-x86_64-list|awk。|sh#cd/home/pqc#tar cf-/usr/share/zoneinfo|tar xvpf-#ln-s bin sbin#mkdir/home/pqc/etc#echo';name=";Post-Quantum Container";&39;>;/home/pqc/etc/os-release#echo&39;root::0:0:root:/root:/bin/sh'。/HOME/pqc/etc/passwd#ECHO根:x:0:>;/etc/group#ECHO';控制台::Respawn:/bin/getty 38400/dev/console';>;/home/pqc/etc/inittab#ECHO';::sysinit:/bin/syslogd';>;/home/pqc/etc/inittab#ECHO&#。/home/pqc/etc/inittab#echo';tssh 2222/tcp';>;/home/pqc/etc/services#echo";tssh stream TCP nowait root/ssh/tinysshd tinysshd-lpsv\n-x sftp=/ssh/sftp-server/etc/tinyssh/sshkeydir";>;/home/pqc/etc/int。

执行上述最后的nspawn命令后,将启动一个新的用户空间,允许您在模拟基本Unix System V的环境中以root用户身份登录:

/home/pqc上的产卵容器pqc。在1秒内按^]三次即可杀死容器。Jun 23 14:44:04 pqc syslog.info syslogd已启动:BusyBox v1.31.0 Jun 23 19:44:04 pqc守护程序.info:正在启动PID 4,tty';';:';/bin/inetd';Jun 23 19:44:04 pqc daemon.err inetd[5]:tssh/tcp:未知服务Jun 23 19:44:04 pqc守护程序。Pqc login:root Jun 23 19:44:06 pqc auth.info login[6]:root登录';console';#ps pid/user-time命令:1 root登录控制台';#0:00 init:3 root登录:0:00/bin/syslogd登录:5 root登录:0:00/bin/inetd#6 root登录:*0:00-sh:7 root:0:00 ps#。

上面的inetd守护进程被配置为启动TinySSH,而TinySSH还没有出现在您的容器映像中。您可以构建TinySSH并返回容器进行安装。

如果您从未见过nspawn容器,请在继续操作之前花一些时间探索它。如果您想要关闭它,请停止它:

#HALT系统现在要关机了!已向所有进程发送SIGTERM Jun 27 21:51:42 pqc daemon.info:系统正在关闭!Jun 27 16:51:42 pqc syslog.info syslogd正在退出将SIGKILL发送到请求系统暂停的所有进程容器pqc已关闭。

如果您在上面的配置中向root帐户添加密码,它将使用/etc/passwd文件中的古老DES散列进行存储。只有nspawn控制台允许密码登录;TinySSH忽略密码。如果您希望使用影子密码,请在容器内运行以下命令:

最后,您需要禁用控制台Getty,只允许通过TinySSH登录。为此,请注释/home/pqc/etc/inittab的第一行,并为systemd放置以下服务文件:

可以通过各种机制在容器内使用glibc和现有主机代码。然而,这可能很困难,因为大多数程序中有大量的依赖项,复制起来可能很乏味。考虑一下Red Hat/CentOS 7上的sshd服务器;将所有49个共享对象正确放置在一个容器中不是一个简单的过程:

$ldd/usr/sbin/sshd linux-vdso.so.1=>;(0x00007ffeec564000)libfipscheck.so.1=>;/lib64/libfipscheck.so.1(0x00007fafbfa3b000)libwrap.so.0=>;/lib64/libwrap.so.0(0x00007fafbf8。Libkeyutils.so.1=>;/lib64/libkeyutils.so.1(0x00007fafb978e000)libattr.so.1=>;/lib64/libattr.so.1(0x00007fafb9589000)libelf.so.1=>;/lib64/libelf.so.1(0x00007fafb9371000)libz2.so.1=&。

MUSL C库允许大幅减少或完全消除编译对象中的运行时链接器依赖。您至少可以使用它来构建功能齐全的TinySSH。

为了构建MUSL,您必须准备好GNU C编译器和相关工具。如果尚未加载它们,则以root身份运行以下命令(在Red Hat/CentOS平台上)获取它们:

大多数安装将在/usr/local/MUSL中进行,但/lib/ld-musl-x86_64.so.1除外(在/lib64中安装会更一致,但是在编译静态二进制文件时奇怪的位置是无关紧要的)。

特别令人感兴趣的是/usr/local/musl/bin/musl-GCC,它是一个简短的shell脚本,它使用具有备用libc链接的system C编译器。

TinySSH在容器或基本OS安装中的灵活性要求在构建过程中稍有不同,主要是将焦点从glibc转移到MUSL,这并不困难。

处于日落支持不同阶段的遗留系统也可以使用TinySSH来实现现代最佳实践密码。Red Hat/CentOS5可以很好地运行TinySSH,尽管旧的HP-UX10.20系统由于缺乏C99支持而无法编译它。注意,Red Hat/CentOS8包括支持NTRU的OpenSSH客户机和服务器;如果您的主机操作系统运行的是OpenSSHV8或更高版本,那么TinySSH实际上只适合容器使用(在Red Hat/CentOS8上启用NTRUkey需要更改/usr/share/crypto-policies/DEFAULT/opensshserver.txt文件)。

$make sh-e make-tinyssh.sh=Sat Jun 27 18:00:33 CDT 2020=正在获取编译器=Sat Jun 27 18:00:34 CDT 2020=检查编译器选项=Sat Jun 27 18:00:34 CDT 2020=Sat Jun 27 18:00:34 CDT 2020。2020年=74069字代码=星期六6月27 18:00:53 CDT 2020=整理=星期六6月27 18:00:53 CDT 2020=计数代码字数=星期六6月27 18:00:53 CDT 2020=星期六6月27 18:00:53 CDT 2020=加密21330。

$LDD build/bin/tinysshd**linux-vdso.so.1=>;(0x00007ffce33e1000)**libutil.so.1=>;/lib64/libutil.so.1(0x00007f53ade04000)**libc.so.6=>;/lib64/libc.so.6(0x00007f53ada36000).。

此二进制文件将非常适合主机操作系统的SSH服务器,但是试图将其放入具有明显依赖关系的nspawn环境中,调用getpwnam()将会失败。与其调试似乎是glibc名称服务开关问题的问题,不如使用MUSL重新构建代码:

与glibc一样,MUSL库也支持使用动态共享对象。如果要在nspawn中使用MUSL环境准备大量编译的C语言,请考虑在容器应用程序中使用共享库来减少内存消耗,甚至可以重新构建BusyBox以使用共享对象。

在任何情况下,都可以以root用户的身份将静态TinySSH二进制文件移动到容器中:

如果您之前暂停了pqc容器,请重新启动它。确保您以root身份登录,并运行以下命令:

这将生成新的ed25519主机密钥。您可能更喜欢使用OpenSSH中的现有密钥;这将在下面讨论。

此外,必须将AUTHORIZED_KEYS文件安装到将托管登录的特定用户帐户中。如果您尚未生成这样的密钥,请生成。对于此测试用例,密钥最好没有密码:

$ssh-keygen-t ed25519-f测试密钥生成公钥/私钥ed25519密钥对。输入密码(如果没有密码,则为空):再次输入相同的密码:您的身份已保存在testkey中。您的公钥已保存在testkey.pub中。关键的指纹是:SHA256:tahsHrY5b0PqNMuxxDew35xS7FoLWNJ6VNOslUNCFao [email protected]关键的随机图片是:+--[ED25519256]--+|{##**|{##**}{##**$$}{##**$$}.o.+。我||我是你的朋友*。||=*||。==。*|*||*.o**||**.o++=*.o||*.o++=*.o|+-[SHA256]-+。

将公钥安装到目标帐户中。此示例使用root。如果您更喜欢非root目标,请创建用户并从nspawn控制台对其进行测试。将密钥安装到相应的容器目录中:

#ssh-p2222-i testkey root@localhost无法确定主机';[localhost]:2222([127.0.0.1]:2222)';的真实性。ED25519型密钥指纹为SHA256:1nnku5/Q8leUwnbB9mDcfPobvsQapj2JJA6FVVQjTJg.。ED25519型密钥指纹为MD5:bc:dc:b6:52:31:8a:59:1d:dc:c7:61:7c:2b:7c:37:01.。是否确实要继续连接(是/否)?是警告:将';[localhost]:2222';(ED25519)永久添加到已知主机列表。输入密钥';testkey';的密码:~#。

容器现在应该为最佳实践SSH登录做好了准备,可以选择使用NTRU(可能的)量子安全密钥交换进行保护。

NTRU密钥的一个问题是,目前只有两个服务器和一个客户端实现它们。如果您幸运的是您的操作系统包含OpenSSH V8或更高版本,您可以直接测试NTRU交换机:

如果您是众多没有运行如此新版OpenSSH的Linux用户之一,那么您可以使用MUSL来创建一个。我将演示OpenSSH的其他组件(sftp-server、scp等)。因此,即使是最新OpenSSH版本的用户也有理由使用MUSL版本。下载最新版本的OpenSSH,然后使用以下命令执行MUSL构建:

$。/configure--help|grep不带-openssl|head-1命令--不带-openssl将禁用OpenSSL;仅使用有限的内部加密**实验性**。

如果使用有密码的密钥,您可能会在MUSL&39;的ssh版本中看到以下错误:

如果是这种情况,请将本机ssh-agent与MUSL ssh客户端一起使用,然后删除ssh命令行上对密钥的LATH-I引用:

$eval$(ssh-agent)代理PID 21067$ssh-add~/testkey输入/HOME/cfish/testkey的密码:身份添加:/home/cfish/testkey(cfish@your host.com)$。/ssh-p 2222\-o [email protected]\root@localhost。

您可能已经注意到inetd引用TinySSH中对sftp-server的引用。如果您想要允许sftp或scp,那么将MUSL构建复制到容器中,并使用正在运行的代理测试登录(请注意,我已经将其称为glibc sftp):

#cp sftp-server/home/pqc/ssh#cp scp/home/pqc/bin$echo';put ssh-agent';|sftp-S。/ssh-o端口=2222\-o [email protected]\root@localhost:/root。

现在不鼓励使用SCP,但它是起作用的。此示例假设有一个正在运行的代理:

如果应该允许非本地主机登录容器,则必须打开端口上的所有防火墙限制。要做到这一点,一种方法是:

如果您曾经打算在OpenSSH和TinySSH服务器之间移动主机密钥,那么TinySSH密钥格式可能会有问题,因为它可能不是OpenSSH期望的格式:

#ls-al/home/pqc/etc/tinyssh/sshkeydir共8个drwxr-xr-x,1个根,0个根,8个月,42月27日18:36。Drwxr-xr-x:1根:0:00,3月18日18:27 18:36.。--rw-1根:0:36.pk 64 Jun 27 18:36.ed25519.sk--rw--r--r-1根:0:--3:32 Jun 27 18:36 ed25519.pk。

Tinysshd-printkey实用程序只能打印公钥。将私钥移动到OpenSSH格式可能需要似乎并不存在的自定义代码。因此,tinysshd-makekey实用程序与生产主机密钥有关。

最好维护与OpenSSH兼容的主机密钥副本,并使用转换器生成TinySSH变体。当前的转换器需要Python3(避免使用较旧的基于C的密钥转换器)。我在Red Hat/CentOS 8上加载了Python转换器:

#python3-m pip install tinyssh-keyConvert-0.3.2.zip警告:以root权限运行pip install通常不是一个好主意。改用`__main__.py安装--用户`。正在处理中。/tinyssh-keyConvert-0.3.2.zip安装收集的软件包:tinyssh-keyConvert为tinyssh-keyConvert运行setup.py install...。已成功安装tinyssh-keyConvert-0.3.2。

OpenSSH ed25519主机密钥通常存储在/etc/ssh/ssh_host_ed25519_key中,应该在没有密码的情况下创建。使用以下命令将此类密钥转换为TinySSH格式:

$tinyssh-keyConvert ssh_host_ed25519_key--dir。$ll ed25519.pk.ed25519.sk-rw-r--r--。1 fish ecj ITG 32 Jun 25 11:57 ed25519.pk-rw-。1 fish ecj ITG 64 Jun 25 11:57.ed25519.sk

将所有相关密钥复制到将使用它们的主机或容器。Ssh_host_ed25519_key.pub公钥并不是严格必需的,因为它可以使用ssh-keygen-y重新生成。请务必在安装完成后删除所有临时副本,因为丢失这些密钥将危及主机的通信安全:

反对上述方法的论据有很多。明显的反对意见包括:NTRU Prime没有得到官方认可;使用MUSL编写标准OpenSSH SSHD并不困难;*TinySSH没有使用特权分离和/或chroot();*TinySSH缺乏重要功能(端口转发、sftp/scp、X11、VPN等);以及应该执行不使用实验功能的更大的MUSL SSH构建。

关于NTRU的官方认可,OpenSSH打算在近期禁用ssh-rsa。对于遗留系统来说,这将是一个创伤性的变化,其中许多系统将只剩下孤立的SSH实现。随着这一级别的变化即将到来,应该施加压力来选择最好的可用的密码系统,并且可以考虑包含TinySSH NTRU Prime。没有管理员想要这样做两次。

与完全实现OpenSSH SSHD相比,TinySSH服务器的配置难度要小得多。服务器的作者声称不能错误配置TinySSH;但对于SSHD则不能这样说。易管理性是一个因素,尤其是在部署到许多服务器时。

TinySSH';的安全记录似乎相当干净,它的设计避免了C的已知问题。此服务器强制执行用户的最佳实践,这可能既是安全优势,也可能是培训责任。也许,特权分离的丧失归根结底是一种合理的交易。

使用OpenSSH,用户可以很容易地了解不良习惯和对外来或过时功能的依赖。这些功能应该简约地扩展到有实际需求的有经验的用户。

最后,如果只将scp和/或sftp服务器组件与TinySSH一起使用,则实验构建可能与此无关。OpenSSL也不包括任何NTRU实现,因此该方面可能不会降级。

为了解决更大的问题,SSH面临着巨大的混乱,RSA密钥立即被弃用和转换(这使得TinySSH省略RSA的决定变得明智)。忽略量子后问题,这个问题是由NIST在2016年提出的,

.