拥抱后量子密码时代:Delegated Credentials来帮忙-阿里云开发者社区

开发者社区> 龙蜥操作系统> 正文
登录阅读全文

拥抱后量子密码时代:Delegated Credentials来帮忙

简介: 当新的算法来临时,我们该如何快速迁移?

编者按:本文作者为蚂蚁集团技术专家刻一,负责BabaSSL密码库产品,也是OpenSSL贡献者之一。在上一篇 技术解析:一文看懂 Anolis OS 国密生态|龙蜥专场 中,国内唯一的一个 OpenSSL maintainer杨洋介绍了BabaSSL,目前,BabaSSL已支持Delegated Credentials,而OpenSSL 还未支持。

D5D8D5F2-B403-46a1-AC4E-20D173437294.png

(图为作者公司版权图片,侵权必究)


前言

在HTTPS通信的场景下,通常在Web服务器上部署证书和密钥,用于身份认证,同时保证消息的完整性。而加密通信的安全性主要取决于加密算法的安全性和密钥的安全性。如果使用了不安全的加密算法,即使攻击者不知道密钥,在只知道密文的前提下,依然可以通过对密文进行分析来实现攻击。例如2020年3月底,研究者公开了Zoom的重大安全漏洞,其中包括,Zoom使用了不安全的加密模式(ECB加密模式),导致了多个知名的公司、教育机构和政府组织宣布,出于信息安全的考虑,禁止使用Zoom,转而使用其他替代产品。


同时,随着近些年量子计算的快速发展,对现代密码学的安全性提出了新的挑战。目前广泛使用的公钥加密算法以RSA和基于椭圆曲线的密码算法为主,而这些算法所基于的数学难题对于经典计算机来说很难,但是对于一个功能足够强大的量子计算机来说可以轻松解决。后量子密码学(PQC)标准化组织致力于研究新的加密算法,以抵抗量子计算,在不久的未来,当新的算法来临时,我们该如何快速迁移?


在加密算法安全的前提下,如何保证密钥的安全性,就成为了关键。尤其是对于部署大量边缘服务器的企业或云计算厂商,将密钥部署在每一台边缘服务器上,如果有一台服务器被黑客入侵,就会导致服务所有站点的密钥泄露,影响范围大,后果非常严重。


Delegated Credentials介绍

Delegated Credentials的意思就是委托凭证,使用服务端(或客户端)证书签发DC,意味着就可以使用DC来代理服务端证书进行TLS握手。而DC本质上就是“迷你证书”,DC公钥的功能对等于证书,DC私钥对等于证书的私钥。


签发DC

X.509标准禁止终端实体证书作为签发者再去签发其他证书,但是只要证书的KeyUsage扩展中包含digitalSignature,就可以用来签发其他签名的对象,而这里对应的就是DC。

X.509标准定义了新的证书扩展,DelegationUsage,表明服务端证书包含这个扩展,才具备签发DC的能力。同时需要终端实体证书的KeyUsage扩展中包含digitalSignature。


服务端认证

  1. ClientHello消息中包含delegated_credential扩展,表明支持DC;
  2. 服务端看到delegated_credential扩展后,如果也支持DC,则在Certificate消息中,发送证书链的同时,在终端实体证书的扩展中携带delegated credential;
  3. 客户端收到Certificate消息后,校验delegated credential,包括签名、有效时间等;
  4. 服务端使用dc的私钥进行签名,然后发送CertificateVerify消息;
  5. 客户端收到CertificateVerify消息后,使用dc公钥来验证签名,完成对服务端的身份认证,同时保证消息的完整性。


对比keyless和Delegated Credentials方案

keyless方案,通过将密钥部署在远程的Back-End(例如KeyServer),在TLS握手的时候,请求Back-End使用密钥进行签名。通过将密钥和边缘服务器隔离,提升密钥的安全性,降低密钥泄露风险。

Client            Front-End            Back-End
     |----ClientHello--->|                    |
     |<---ServerHello----|                    |
     |<---Certificate----|                    |
     |                   |<---remote sign---->|
     |<---CertVerify-----|                    |
     |        ...        |                    |

而DC方案,同样在Back-End上部署证书和密钥,提前签发DC后并部署在边缘服务器上(Front-End)。


和keyless相比的优点:

  • keyless需要改造TLS握手处理过程,修改密码库(例如OpenSSL)支持keyless,而DC不需要
  • keyless在TLS握手时请求Back-End服务器,增加了握手的延时,而DC签发、部署可以异步离线执行
Client            Front-End            Back-End
     |                   |<--DC distribution->|
     |----ClientHello--->|                    |
     |<---ServerHello----|                    |
     |<---Certificate----|                    |
     |<---CertVerify-----|                    |
     |        ...        |                    |


Delegated Credentials优势

自主签发

通常,服务端证书或客户端证书是由证书认证机构(CA)来签发,一般有效期不超过1年,在证书过期之前需要找CA重新签发证书。如果想要签发短期的证书,意味着要与CA机构进行频繁的交互,等待CA审核通过后,下载证书重新部署。而短期的证书意味着证书的有效期更短,如果CA相应不及时,可能导致证书过期的风险。


引入Delegated Credentials后,就可以使用服务端(或客户端)证书来签发DC,而不需要依赖于外部CA。通过DC来代理终端实体证书,完成TLS通信。


使用更安全的算法

正是因为自主签发,我们可以选择更安全的签名算法,例如Ed25519,而CA通常不支持。


每次签发DC时,都可以选择使用最安全的签名算法,可以及时淘汰老旧的、不安全的算法,保证通信的安全性。


周期短

DC的有效期最长不能超过7天,更短的周期意味着频繁的轮转,降低密钥泄露的风险,提升安全性。


注意,因为周期短,DC不支持吊销。


Delegated Credentials支持现状

DC既需要服务端支持,也需要客户端支持,目前支持DC的浏览器并不多,以Firefox为主。


支持DC的开源密码库包括Google的BoringSSL、Firefox的NSS、蚂蚁的BabaSSL,目前OpenSSL还不支持DC。


BabaSSL发布的8.2.0版本支持Delegated Credentials,且已经合并到开源BabaSSL,欢迎大家使用内部RPM包或开源版本。


实战Delegated Credentials

签发DC

注意:需要使用BabaSSL才能签发dc,开源OpenSSL并不支持。


完整的脚本请参考BabaSSL开源代码库,https://github.com/BabaSSL/BabaSSL/blob/master/test/recipes/80-test_dc_sign_data/sign_dc.sh

# 创建dc密钥
openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out dc-ecc-server-longterm.key
# 签发dc
openssl delecred -new -server -sec 604800 -dc_key dc-ecc-server-longterm.key -out dc-ecc-server-longterm.dc -parent_cert dc-ecc-leaf.crt -parent_key dc-ecc-leaf.key -expect_verify_md sha256 -sha256

使用DC通信

认证服务端:

# server端
openssl s_server -accept 127.0.0.1:4433 -cert dc-ecc-leaf.crt -dc_pkey dc-ecc-server-longterm.key -dc dc-ecc-server-longterm.dc -enable_sign_by_dc
# client端
openssl s_client -connect 127.0.0.1:4433 -enable_verify_peer_by_dc -verifyCAfile dc-ecc-chain-ca.crt -verify_return_error

双向认证:

# server端
openssl s_server -accept 127.0.0.1:4433 -cert dc-ecc-leaf.crt -dc_pkey dc-ecc-server-longterm.key -dc dc-ecc-server-longterm.dc -enable_sign_by_dc -enable_verify_peer_by_dc -Verify 1 -verifyCAfile dc-ecc-chain-ca.crt -verify_return_error
# client端
openssl s_client -connect 127.0.0.1:4433 -cert dc-ecc-leaf-clientUse.crt -dc_pkey dc-ecc-client-longterm.key -dc dc-ecc-client-longterm.dc -enable_verify_peer_by_dc -enable_sign_by_dc -verifyCAfile dc-ecc-chain-ca.crt -verify_return_error

应用基于BabaSSL集成DC

SSL *s;
    SSL_CTX *ctx;
    DELEGATED_CREDENTIAL *dc = NULL;
    ctx = SSL_CTX_new(TLS_server_method());
    if (ctx == NULL) {
        // error
    }
    
    // 设置证书
    if (!SSL_CTX_use_certificate_file(ctx, cert_file, SSL_FILETYPE_PEM)) {
        // error
    }
    // 设置证书的密钥
    if (!SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM)) {
        // error
    }
    
    // 加载DC文件,注意:必须先加载服务端(或客户端)证书,再加载DC
    if (!SSL_CTX_use_dc_file(ctx, cert_file, 0)) {
        // error
    }
    
    // 加载DC的密钥
    if (!SSL_CTX_use_dc_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM)) {
        // error
    }
    
    //功能:开启dc签名功能,server在开启该功能并收到dc请求时才会选择使用dc进行签名
    SSL_CTX_enable_sign_by_dc(ctx);
    ...
        
    s = SSL_new(ctx);
    
    ...

参考

  1. Delegated Credentials for TLS, draft-ietf-tls-subcerts-10
  2. 开源BabaSSL代码仓库

————


加入龙蜥社群

加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】拉你入群;加入钉钉群:扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥OpenAnolis社区交流,共同推进龙蜥社区的发展,一起打造一个活跃的、健康的开源操作系统生态!

1.jpeg            龙蜥助手.jpeg

龙蜥社区钉钉交流群              龙蜥社区_小龙


关于龙蜥社区

龙蜥社区(OpenAnolis)是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于2020年9月,旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。


短期目标是开发龙蜥操作系统(Anolis OS)作为CentOS替代版,重新构建一个兼容国际Linux主流厂商发行版。中长期目标是探索打造一个面向未来的操作系统,建立统一的开源操作系统生态,孵化创新开源项目,繁荣开源生态。


龙蜥OS 8.4已发布,支持x86_64和ARM64架构,完善适配Intel、飞腾、海光、兆芯、鲲鹏芯片。欢迎下载:https://openanolis.cn/download


加入我们,一起打造面向未来的开源操作系统!

Https://openanolis.cn

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

龙蜥社区(OpenAnolis)是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于2020年9月,旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。

官方博客
最新文章
相关文章
官网链接