还在嫌弃你的浏览器下载巨慢？

统信UOS的安全设计主要有四大方面：

1、限制超级用户

统信UOS对所有特权程序进行了处理，包括setuid权限和capabilities的可执行程序。前端应用程序都去掉了这些特权，只有通过后端有特权的服务器获取相应的功能。

前端应用程序和后端服务器之间的通信主要是通过dbus进行保证，而dbus本身也可以通过polkit的方式进行权限限制。

这样，普通用户就不会轻易获得特殊权限，不会轻易的破坏系统安全性、形成系统安全漏洞，造成不必要的损失。

 

说起国产操作系统的重点和难点，除了生态，就是安全了，毕竟……你懂的。

8月12日，第八届互联网安全大会（ISC 2020）信创安全论坛在线举行，统信软件高级副总经理、总工程师张磊受邀发表《统信操作系统安全设计与规划》演讲，分享了对操作系统安全体系建设的思考，以及统信UOS安全体系建设实践经验。

统信UOS底层基于开源的Linux，它本身虽然在安全方面就有诸多考虑，但仍存在严重不足，比如软件分发方式多且复杂，应用软件和系统没有隔离，应用程序广泛使用动态链接造成了非常复杂的网状软件治理体系。

 

在这个过程结束时，client 程序和 Google Web 服务器现在拥有相同的 PMS 位。每一方都使用这些位生成一个主密码master secret，并立即生成一个称为会话密钥session key的对称加密/解密密钥。现在有两个不同但等价的会话密钥，连接的每一方都有一个。在 client 的例子中，会话密钥是 AES128 类的。一旦在 client 程序和 Google Web 服务器两边生成了会话密钥，每一边的会话密钥就会对双方的对话进行保密。如果任何一方（例如，client 程序）或另一方（在这种情况下，Google Web 服务器）要求重新开始握手，握手协议（如 Diffie-Hellman）允许整个 PMS 过程重复进行。

总结

在命令行上说明的 OpenSSL 操作也可以通过底层库的 API 完成。这两篇文章重点使用了这个实用程序，以保持例子的简短，并专注于加密主题。如果你对安全问题感兴趣，OpenSSL 是一个很好的开始地方，并值得深入研究。

 

所产生的哈希值匹配，从而确认数字证书是基于指定的密钥对。

回到密钥分发问题上

让我们回到第一部分末尾提出的一个问题：client 程序和 Google Web 服务器之间的 TLS 握手。握手协议有很多种，即使是用在 client 例子中的 Diffie-Hellman 版本也有不同的方式。尽管如此，client 例子遵循了一个共同的模式。

首先，在 TLS 握手过程中，client 程序和 Web 服务器就加密套件cipher suite达成一致，其中包括要使用的算法。在本例中，该套件是 ECDHE-RSA-AES128-GCM-SHA256。

现在值得关注的两个要素是 RSA 密钥对算法和 AES128 块密码，用于在握手成功的情况下对消息进行加密和解密。关于加密/解密，这个过程有两种流派：对称symmetric和非对称asymmetric。在对称流派中，加密和解密使用的是相同的密钥，这首先就引出了密钥分发问题key distribution problem。如何将密钥安全地分发给双方？在非对称流派中，一个密钥用于加密（在这种情况下，是 RSA 公钥），但另一个密钥用于解密（在这种情况下，是来自同一对密钥的 RSA 私钥）。

client 程序拥有来认证证书的 Google Web 服务器的公钥，而 Web 服务器拥有来自同一对密钥的私钥。因此，client 程序可以向 Web 服务器发送加密信息，而 Web 服务器可以单独对该通信进行解密。

在 TLS 的情况下，对称方式有两个显著的优势：

• 在 client 程序与 Google Web 服务器之间的互动中，认证是单向的。Google Web 服务器向 client 程序发送三张证书，但 client 程序并没有向 Web 服务器发送证书，因此，Web 服务器没有来自客户端的公钥，无法加密发给客户端的消息。
• 使用 AES128 的对称加密/解密比使用 RSA 密钥的非对称加密/解密快了近千倍。

TLS 握手将两种加密/解密方式巧妙地结合在一起。在握手过程中，client 程序会生成随机位，即所谓的预主密pre-master secret（PMS）。然后，client 程序用服务器的公钥对 PMS 进行加密，并将加密后的 PMS 发送给服务器，服务器再用 RSA 密钥对的私钥对 PMS 信息进行解密：

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!