Network Working Group D. Zhang
Internet-Draft
Intended status: Experimental D. Gillmor
Expires: January 6, 2016 CMRG
D. He
Huawei
B. Sarikaya
Huawei USA
July 5, 2015
CT for Binary Codes
draft-zhang-trans-ct-binary-codes-03
Abstract
This document proposes a solution to use Certificate Transparency for
publishing software (or the digest of 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 January 1, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires January 1, 2016 [Page 1]
Internet-Draft CT for Binary Codes June 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
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 software. Through verifying
signatures, an end user can ensure that the software she gets is
developed by a legal provider (e.g., Microsoft) and is not tampered
during the distribution. If an end user does not have a direct trust
relationship with the software provider, an authentication chain
needs 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 public key
infrastructure (PKI).
However, signatures cannot prevent software provider from
distributing software 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 describes a mechanism which extends the Certificate
Transparency (CT) specified in [I-D.ietf-trans-rfc6962-bis] to
support logging binary codes. A software provider can publish its
binary codes (or digests of codes in order to e.g., save space or
Zhang, et al. Expires January 1, 2016 [Page 2]
Internet-Draft CT for Binary Codes June 2015
avoid violating license restrictions) to one or more CT logs.
Therefore, a user can easily detect whether there are customized
backdoors by monitoring the log records.
IIn this mechanism, after a section of binary codes has been
published to a log, the log will return a ticket (called Signed
Certificate Timestamp (SCT) in this case) to the software provider.
In this mechanism, the software without the ticket MUST NOT be
trusted even if it is associated with a proper signature. This
approach then forces the software providers to publish their binary
codes to logs before distributing them.
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
The documents disclosed by Edward Snowden 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 also
meet 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 facilities 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,
under the assistance of the binary transparency, customer will have
more confidence on the quality of firmware. Since the same codes are
used by different customers all over the world, the drawbacks in
firmware will be easier to be detected.
There are similar requirements to detect the customized backdoors in
the software market. Besides the software itself, a user may also
concern whether there are customized backdoors in the patches. the
binary transparency can help address such concerns in the same way.
In addtion, this mechanism can also show some advantages in the
scenarios where the signer does not realize that their keys have been
compromised. If their update system requires using a CT log they
could find out about their compromise.
Zhang, et al. Expires January 1, 2016 [Page 3]
Internet-Draft CT for Binary Codes June 2015
4. Log Format and Operation
4.1. Log Entries
A developer/issuer of software can submit the software and the
associated signature to any preferred CT logs before distributing it.
In some cases, the software developer may select only to publish the
signed digest of the software because of the license restriction or
the space restriction of log record. In order to verify the
attribution of each log record, a log SHALL publish a set of
certificates that it trusts to benefit an issuer to construct an
authentication chain connecting a trust anchor and the certificate
containing the key used to sign the software.
A log needs to verify the authentication chain provided by the
issuer, and MUST refuse to accept the signed software/digest if the
chain cannot lead back to a trusted anchor. If the software/digest
and the signature are accepted by a log and an SCT is issued, the log
MUST store the entire 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;
enum { binary(TBD3), binary_digest(TBD4) } Signed_Type;
struct {
LogEntryType entry_type;
Signed_Type signed_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.
Zhang, et al. Expires January 1, 2016 [Page 4]
Internet-Draft CT for Binary Codes June 2015
signed_type indicates whether the signature is generated based on the
software or its digest.
"signed_software" consists a ContentInfo structure specified in
CMS[RFC5652]. Specifically, this field includes the binary codes/
digest, the signature, and any other additional information used to
describe the software and the issuer publishing the software. The
software SHOULD encapsulated and signed following the ways specified
in CMS[RFC5652] . If signed_type is TBD3, the software is
encapsulated in this field. If signed_type is TBD4, the SHA-256
digest of software is encapsulated in this field.
"certificate_chain" includes the certificates constructing a chain
from the certificate of issuer to a certificate trusted by the log.
The first certificate MUST be the certificate of issuer. 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. if the informaiton chain is provided
in the signed_software field, this field is set to empty.
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 makes
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.
Zhang, et al. Expires January 1, 2016 [Page 5]
Internet-Draft CT for Binary Codes June 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" are are identical to what is
defined in Section 3.3 of [I-D.ietf-trans-rfc6962-bis].
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://<log server>/ct/v1/add-Binary-chain
Inputs:
software: the binary code(or digest), the signature, and the
information used to describe the software and the signer
publishing the software, which are encapsulated following the
ways specified in CMS[RFC5652] .
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
Zhang, et al. Expires January 1, 2016 [Page 6]
Internet-Draft CT for Binary Codes June 2015
known root certificate. If the certificate chain information
has been incuded in the software field, this field could be
empty.
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 specified a new LogEntryType value TBD1, and a new
SignatureType value TBD2.
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.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
Zhang, et al. Expires January 1, 2016 [Page 7]
Internet-Draft CT for Binary Codes June 2015
[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 January 1, 2016 [Page 8]