Network Working Group D. Zhang Internet-Draft Intended status: Experimental D. Gillmor Expires: November 6, 2015 CMRG D. He Huawei B. Sarikaya Huawei USA May 5, 2015 CT for Binary Codes draft-zhang-trans-ct-binary-codes-02 Abstract This document proposes a solution to use CT for publishing softwares/ binary codes and their signatures. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 6, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires November 6, 2015 [Page 1] Internet-Draft CT for Binary Codes May 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Cryptographic Components of Certificate Transparency . . . . 3 3. Motivation Scenarios . . . . . . . . . . . . . . . . . . . . 3 3.1. Dealing with Customized Backdoors in Firmwares . . . . . 3 3.2. Another Scenarios . . . . . . . . . . . . . . . . . . . . 3 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 4 4.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Structure of the Signed Certificate Timestamp . . . . . . 5 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 6 5.1. Add Binary and Certificate Chain to Log . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Digital signatures have been widely used in software distributions to demonstrate the authenticity of softwares. Through verifying signatures, end users can could ensure that the softwares they got are provided by legal organizations and never modified during the delivery. If an end user does not have a direct trust relationship with the software provider, an authentication chain need to be generated from the key used for generating the signature to a trust anchor that the user trusts. That is why many signature mechanisms for software distribution are based on PKI. However, signatures cannot prevent a software developer from distributing softwares with customized backdoors/drawbacks. In some circumstances, it may be hard for a user to detect the differences between the software it got and the software provided to other users. This draft describe a mechanism to extend Certificate Transparency specified in [I-D.ietf-trans-rfc6962-bis] to support logging binary codes. A software provider can publish its softwares (or digests of Zhang, et al. Expires November 6, 2015 [Page 2] Internet-Draft CT for Binary Codes May 2015 binary codes in the cases the softwares are non-trivial) to one or more logs. Therefore, a user can easily detect the customized backdoors through monitoring the log entries. In this mechanism, after a section of binary codes is published to a log, the log will return a ticket (called Signed Certificate Timestamp (SCT) in this case) to the software provider. The software without the ticket will not be trusted even it is associated with a proper signature. This approach will force providers to publish their binary codes to logs. 2. Cryptographic Components of Certificate Transparency The introduction of cryptographic components of CT is in Section 2 of [I-D.ietf-trans-rfc6962-bis]. When applying CT for binary codes, a log is a single, ever-growing, append-only Merkle Tree of Delegation Signer (DS) Resource Records (RRs). 3. Motivation Scenarios 3.1. Dealing with Customized Backdoors in Firmwares The disclosed documents have raised the concerns of people on the vulnerability of the network devices to the passive attacks performed by NSA or other organizations. Some vendors have met problems in their foreign markets because their products are suspected to have customized backdoors for adversaries to perform attacks. It is desired for vendors to publish the design details of the products and provide sufficient functions for clients to check whether certain hardware or software of a device has been improperly modified. There are various techniques that could be used for this purpose. One way is to force a vendor to publish the binary codes of its firmwares. Therefore, customers can easily detect whether the vendor is releasing the same firmware to everyone. In addition, the binary transparency, customer will have more confidence on the quality of firmwares. Since the same codes are used by different customers all over the world, the drawbacks in firmwares will be easier to be detected. 3.2. Another Scenarios Ben suggested to us CT for publishing FreeBSD. Can you contribute some ideas here? Zhang, et al. Expires November 6, 2015 [Page 3] Internet-Draft CT for Binary Codes May 2015 4. Log Format and Operation 4.1. Log Entries A developer of a software can submit the signed software (or the digest of the software to save space) to any preferred logs before distributing it. In order to enable attribution of each logged RR to its issuer, the log SHALL publish a list of certificates to construct an authentication chain connecting the trust anchor and the certificate used to sign the software. Logs MUST verify the authentication chain and make sure it leads back to a trusted certificate, using the chain of certificates provided by the submitter. Logs MUST refuse to publish a signed software without a valid chain. If the software and the signature are accepted and an SCT issued, the accepting log MUST store the entire chain used for verification, including the signed software itself and including the trusted zone signing key used to verify the chain, and MUST present this chain for auditing upon request. To comply with the certificate entries specified in [I-D.ietf-trans-rfc6962-bis], each software entry in a log MUST include the following components: enum { x509_entry(0), precert_entry(1), BIN_entry(TBD1), (65535) } LogEntryType; struct { LogEntryType entry_type; select (entry_type) { case x509_entry: X509ChainEntry; case precert_entry: PrecertChainEntry; case BINARY_entry:SigSoft_Chain_Entry } entry; } LogEntry; opaque BINARY<1..2^24-1>; struct { BINARY signed_software; ASN.1Cert certificate_chain<0..2^24-1>; } BINARY_Chain_Entry; "entry_type" is the type of this entry. the type value of a binary log entry is TBD1. "signed_software" include the binary codes, the signature, and any other additional information used to describe the software and the signer publishing the software. The current version of the document Zhang, et al. Expires November 6, 2015 [Page 4] Internet-Draft CT for Binary Codes May 2015 does not specify how to structure such information. (CMS[RFC5652] can be used.) This work will be left for future work. "certificate_chain" include the certificates constructing a chain from the certificate of signer to a certificate trusted by the log. The first certificate MUST be the certificate of signer. Each following certificate MUST directly certify the one preceding it. The final certificate MUST either be, or be issued by, a root certificate accepted by the log. 4.2. Structure of the Signed Certificate Timestamp This work reuses the structure of Signed Certificate Timestamp (SCT) specified in Section 3.3 of [I-D.ietf-trans-rfc6962-bis] but make necessary extensions. enum { certificate_timestamp(0), tree_hash(1),BINARY_timestamp(TBD2), (255) } SignatureType; enum { v1(0), (255) } Version; struct { opaque key_id[32]; } LogID; opaque digestcodes<0..2^24-1>; struct { opaque issuer_key_hash[32]; digestcodes binary_digest; } Binary_Codes; opaque CtExtensions<0..2^16-1>; "key_id" and "issuer_key_hash" are defined in Section 3.3 of [I-D.ietf-trans-rfc6962-bis]. binary_digest is the SHA-256 hash of binary codes. (Open question: In the future version of the this document, do we need to support other digest algorithms? If so, maybe we should provide an digest identifier field here. ) Zhang, et al. Expires November 6, 2015 [Page 5] Internet-Draft CT for Binary Codes May 2015 struct { Version sct_version; LogID id; uint64 timestamp; CtExtensions extensions; digitally-signed struct { Version sct_version; SignatureType signature_type = DSRR_timestamp; uint64 timestamp; LogEntryType entry_type; select(entry_type) { case x509_entry: ASN.1Cert; case precert_entry: PreCert; case BINARY_entry: Binary_Codes; } signed_entry; CtExtensions extensions; }; } SignedCertificateTimestamp; "sct_version", "timestamp", "entry_type and extensions" are are identical to what is defined in Section 3.3 of [I-D.ietf-trans-rfc6962-bis].. "extensions" are future extensions to this protocol version (v1). Currently, no extensions are specified. 5. Log Client Messages In Section 4 of [I-D.ietf-trans-rfc6962-bis], a set of messages is defined for clients to query and verfiy the correctness of the log entries they are interested in. In this memo, two new messages are defined for CT to support binary transparency. 5.1. Add Binary and Certificate Chain to Log POST https:///ct/v1/add-Binary-chain Inputs: software: the binary code, the signature, and the information used to describe the software and the signer publishing the software Zhang, et al. Expires November 6, 2015 [Page 6] Internet-Draft CT for Binary Codes May 2015 chain: An array of base64-encoded certificates. The first element is the certificate used to sign the binary codes; the second chains to the first and so on to the last, which is either the root certificate or a certificate that chains to a known root certificate. Outputs: sct_version: The version of the SignedCertificateTimestamp structure, in decimal. A compliant v1 implementation MUST NOT expect this to be 0 (i.e., v1). id: The log ID, base64 encoded. timestamp: The SCT timestamp, which is the current NTP Time [RFC5905], measured since the epoch (January 1, 1970, 00:00), ignoring leap seconds, in milliseconds. extensions: An opaque type for future expansion. It is likely that not all participants will need to understand data in this field. Logs should set this to the empty string. Clients should decode the base64-encoded data and include it in the SCT. signature: The SCT signature, base64 encoded. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations 8. Acknowledgements 9. Normative References [I-D.ietf-trans-rfc6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency", draft-ietf-trans- rfc6962-bis-07 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Zhang, et al. Expires November 6, 2015 [Page 7] Internet-Draft CT for Binary Codes May 2015 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. Authors' Addresses Dacheng Zhang Email: dacheng.zhang@gmail.com Daniel Kahn Gillmor CMRG Email: dkg@fifthhorseman.net Danping He Huawei Email: ana.hedanping@huawei.com Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 3 Plano, TX 75024 Email: sarikaya@ieee.org Zhang, et al. Expires November 6, 2015 [Page 8]