文章主要介绍了AWS KMS云服务开始支持Post-Quantum Cryptography (PQC) 的签名算法,特别是ML-DSA。作者分享了在AWS上使用ML-DSA签名密钥的实践过程,包括如何创建、配置以及通过AWS CLI进行操作。最后,作者表达了对PQC技术在云安全领域应用的乐观态度,并展望了未来基于格和哈希签名的新型数字信任体系。
不管你喜欢与否,我们现在在网上所做的大部分事情都是在云中处理和存储的。但是,我们遇到了一个问题,Peter Shorr 证明了使用大规模构建的量子计算机可以破解我们现有的所有公钥密码学方法。因此,NIST 已经确定我们需要在 2030 年之前弃用我们所有的密钥交换方法 (ECDH)、我们所有的数字签名方法 (RSA PSS, RSA PKCS#1 v1.5, ECDSA 和 EdDSA) 以及我们所有的公钥加密方法 (RSA OAEP),然后在 2035 年之前删除它们。当我说“所有”时,我的意思是“所有”。对于“现在存储,以后泄露”的风险尤其如此,其中对手可以大规模收集我们的在线加密数据,然后在未来破解它。互联网的安全和隐私几乎将被完全破坏。
因此,我们的许多加密方法现在都在云中完成,因此我们需要将我们现有的方法迁移到 PQC 安全方法。为此,我们有用于替换 ECDH 和 RSA OAEP 的 ML-KEM(Kyber)以及用于替换 RSA PSS、RSA PKCSv1、ECDSA 和 EdDSA 的 ML-DSA(Dilithium)。因此,AWS 宣布他们现在已经迁移到 PQC 方法,这真是太棒了,我打开了我的 AWS KMS,但遗憾的发现没有用于签名的 PQC 密钥:
因此,我去了 LinkedIn,询问是否有人成功使用它,很高兴收到回复:
因此,我的北弗吉尼亚地区尚不支持 ML-DSA,所以我搬到了北加利福尼亚 (us-west-1),它奏效了:
经过多年的 PQC 推动,我很高兴看到漂亮的 ML-DSA-44、ML-DSA-65 和 ML-DSA-87 密钥:
{
"Id": "key-consolepolicy-3",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ZZZZ:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access for Key Administrators",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::ZZZZ:user/awstest",
]
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::ZZZZ:user/awstest",
]
},
"Action": [
"kms:DescribeKey",
"kms:GetPublicKey",
"kms:Sign",
"kms:Verify"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam:: ZZZZ:user/awstest",
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
然后,创建后,我可以查看公钥:
对于密钥交换和加密部分,它仍然有我们现有的公钥方法,但我相信这种情况很快就会改变:
然后,我在 AWS CLI 上将我的区域更改为 us-west-1:
% aws configure --region us-west-1
AWS Access Key ID [****************ZZZZ]: ZZZZ
AWS Secret Access Key [****************ZZZ]: ZZZ
Default region name [us-east-1]: us-west-1
Default output format [None]:
它完美地工作了:
% aws kms create-key --key-spec ML_DSA_65 --key-usage SIGN_VERIFY
{
"KeyMetadata": {
"AWSAccountId": "ZZZZ",
"KeyId": "8dccc2fc-a118-441f-84d6-bededc896f67",
"Arn": "arn:aws:kms:us-west-1:zzzzzzz:key/8dccc2fc-a118-441f-84d6-bededc896f67",
"CreationDate": "2025-06-19T08:22:15.408000+01:00",
"Enabled": true,
"Description": "",
"KeyUsage": "SIGN_VERIFY",
"KeyState": "Enabled",
"Origin": "AWS_KMS",
"KeyManager": "CUSTOMER",
"CustomerMasterKeySpec": "ML_DSA_65",
"KeySpec": "ML_DSA_65",
"SigningAlgorithms": [
"ML_DSA_SHAKE_256"
],
"MultiRegion": false
}
}
而且,我有两个 PQC 签名密钥:
如果你有兴趣,这里是这些密钥的大小(来自 AWS 文档此处):
因此,密钥比 ECDSA 和 EdDSA 略大,但仍然相当易于管理。签名大小也合理。
欢迎来到云和网络安全新时代的曙光,并与 RSA 和椭圆曲线方法告别——它们为我们提供了很好的服务,但它们在保护互联网方面的时间现在已经屈指可数了。由于 NIST 和研究界多年的辛勤工作,今天是一个伟大的日子,也是数字信任新未来的开始,这个未来是基于格和哈希签名,而不是 RSA 和 ECC。
现在,我要去测试我的 Boto3 Python 集成了。
- 原文链接: medium.com/asecuritysite...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!