25个重大版本发布
0.26.0 | 2023年11月7日 |
---|---|
0.24.0 | 2023年7月24日 |
0.22.0 | 2023年3月19日 |
0.20.0 | 2022年12月30日 |
0.3.0 | 2021年5月6日 |
#401 in 加密学
12,699 每月下载次数
在 18 个crate中使用 (直接使用4个)
350KB
7K SLoC
cryptographic-message-syntax
cryptographic-message-syntax
is a pure Rust implementation of Cryptographic Message Syntax (CMS) as defined by RFC 5652. Also included is Time-Stamp Protocol (TSP) (RFC 3161) client support.
From a high level CMS defines a way to digitally sign and authenticate arbitrary content.
This crate was originally developed to support code signing on Apple platforms. (See the apple-codesign
Rust crate.) However, it is a generic library crate. But some historical decisions from its original may remain.
lib.rs
:
Cryptographic Message Syntax (RFC 5652) in Pure Rust
This crate attempts to implement parts of RFC 5652 in pure, safe Rust.
Functionality includes
- Partial (de)serialization support for ASN.1 data structures. The Rust structs are all defined. But not everything has (de)serialization code implemented.
- High-level Rust API for extracting useful attributes from a parsed
SignedData
structure and performing common operations, such as verifying signature integrity.
RFC 5652 is quite old. If you are looking to digitally sign content, you may want to look at something newer, such as RPKI (RFC 6488). (RPKI appears to be the spiritual success to this specification.)
IMPORTANT SECURITY LIMITATIONS
The verification functionality in this crate is purposefully limited and isn't sufficient for trusting signed data. You need to include additional trust verification if you are using this crate for verifying signed data.
This crate exposes functionality to verify signatures and content integrity of signed data. Specifically it can verify that an embedded cryptographic signature over some arbitrary/embedded content was issued by a known signing certificate. This answers the question did certificate X sign content Y. This is an important question to answer, but it fails to answer other important questions such as
- Is the signature cryptographically strong or weak? Do I trust the signature?
- Do I trust the signer?
Answering do I trust the signer is an extremely difficult and nuanced problem. It entails things like
- Ensuring the signing certificate is using secure cryptography.
- Validating that the signing certificate is one you think it was or was issued by a trusted party.
- Validating the certificate isn't expired or hasn't been revoked.
- 验证证书是否包含所需的属性/扩展(例如,证书可以标记为用于代码签名)。
如果您将此crate用作验证签名内容的一部分,您需要回答以下难题。这可能需要编写超出此crate中可用代码的代码。理想情况下,您想使用现有的库来完成此操作,因为正确完成此操作很困难。理想情况下,您应该咨询安全/密码学领域的专家以获得帮助。
技术备注
RFC 5652基于PKCS #7版本1.5(RFC 2315)。因此,与PKCS #7交互的常见工具/库可能可以成功解析此格式。例如,您可以使用OpenSSL读取数据结构
$ openssl pkcs7 -inform DER -in -print $ openssl pkcs7 -inform PEM -in -print $ openssl asn1parse -inform DER -in
RFC 5652使用BER(非DER)进行序列化。曾尝试使用其他更流行的BER/DER/ASN.1序列化crate。然而,我们只能让bcder
工作。在类似的方式中,还有其他crate实现了对常用ASN.1功能的支持,例如序列化X.509证书。同样,许多这些依赖于看起来与BER不兼容的序列化器。因此,我们递归定义了RFC5652引用的ASN.1数据结构,并教它们使用bcder
进行序列化。
依赖项
~11–24MB
~458K SLoC