拥抱后量子密码时代: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

相关实践学习
CentOS 7迁移Anolis OS 7
龙蜥操作系统Anolis OS的体验。Anolis OS 7生态上和依赖管理上保持跟CentOS 7.x兼容,一键式迁移脚本centos2anolis.py。本文为您介绍如何通过AOMS迁移工具实现CentOS 7.x到Anolis OS 7的迁移。
相关文章
|
19天前
|
安全 量子技术 数据安全/隐私保护
解密未来:量子加密技术在信息安全领域的革新展望
【10月更文挑战第28天】信息安全是现代社会的重要组成部分,量子加密技术作为新兴手段,利用量子力学原理,为信息安全带来革命性变革。本文介绍量子密钥分发(QKD)的基本原理,并通过代码示例展示其实际应用潜力。量子加密具有无条件安全、抗量子计算攻击等优势,未来有望成为保护信息安全的重要工具。
34 6
|
25天前
|
人工智能 算法
人工智能浪潮中的伦理困境:我们如何确保技术的道德发展?
【10月更文挑战第22天】在人工智能(AI)技术的迅猛发展中,伴随着巨大的潜力和便利性,也出现了众多伦理问题。从数据隐私到算法偏见,再到自动化带来的失业问题,AI的每一步进步都在考验着人类社会的道德底线。本文将探讨AI技术发展中的主要伦理问题,并讨论如何通过制定标准、教育和跨学科合作来确保AI技术的道德发展。
|
3月前
|
传感器 物联网 区块链
未来已来:新兴技术在塑造现代社会中的角色
【8月更文挑战第11天】本文深入探讨了区块链、物联网和虚拟现实等新兴技术的发展现状与未来趋势。通过分析这些技术的实际应用案例,我们揭示了它们如何改变我们的工作、生活和社交方式。文章旨在提供一个全面的视角,帮助读者理解这些技术背后的潜力及其对社会的深远影响。
|
4月前
|
机器学习/深度学习 并行计算 算法
探索未来:量子计算在现代科技革命中的角色
随着科技的不断进步,量子计算作为一项前沿技术,正逐渐从理论走向实践应用。本文将深入探讨量子计算的核心原理、当前发展现状以及面临的挑战,并展望未来量子计算对各行各业可能带来的影响。通过具体数据和实例,我们将揭示量子计算如何成为推动现代科技革命的关键力量。
|
5月前
|
安全 算法 网络安全
未来之光:量子计算与加密技术的新纪元
【6月更文挑战第12天】本文探讨了量子计算在现代加密技术中的影响,分析了量子计算机对传统加密算法的威胁,并提出了应对策略。随着量子计算的发展,加密技术面临前所未有的挑战与机遇。文章通过深入分析,揭示了量子加密的潜力及其对未来网络安全的重要性。
|
5月前
|
机器学习/深度学习 人工智能 算法
探索量子计算:未来技术的新篇章
【6月更文挑战第16天】本文将深入探讨量子计算的基本原理、发展现状以及其对未来科技领域的潜在影响。我们将通过一个创新的视角,分析量子计算如何在解决复杂问题、加速数据处理和推动科学研究方面展现出前所未有的能力。文章旨在为读者提供一个关于量子计算技术发展的全面视角,同时探讨它如何塑造我们未来的技术景观。
|
供应链 监控 物联网
区块链革命的颠覆性到底在哪里?
区块链革命的颠覆性到底在哪里?
203 0
区块链革命的颠覆性到底在哪里?
|
人工智能 算法 自动驾驶
人工智能技术迅猛发展,AI信任问题如何破解?
说到AI,首先你会想到的是什么?是九段天才棋手柯洁大战AlphaGo?是自动驾驶?还是跟朋友聊到某个话题时手机秒推送的同类广告? 抑或是让父母都认不出来的“易容神器”?
|
运维 监控 安全
【科普】TLS1.3如此强大!我们如何迎接它?
由阿里云CDN技术专家林胜恩(啸坤)为你详细揭秘TLS1.3的发展历程、特性以及应用。
4142 1
【科普】TLS1.3如此强大!我们如何迎接它?
|
算法 定位技术 量子技术

热门文章

最新文章

下一篇
无影云桌面