| Network Working Group | R. Tse |
| Internet-Draft | Ribose |
| Updates: 4880, 6637 (if approved) | W. Wong |
| Intended status: Standards Track | Hang Seng Management College |
| Expires: May 31, 2018 | J. Lloyd |
| D. Wyatt | |
| E. Borsboom | |
| Ribose | |
| November 27, 2017 |
OSCCA Extensions For OpenPGP
draft-ribose-openpgp-oscca-01
This document enables OpenPGP (RFC4880) usage in an compliant manner with OSCCA (Office of State Commercial Cipher Administration) regulations for use within China.
Specifically, it extends OpenPGP to support the usage of SM2, SM3 and SM4 algorithms, and provides the OSCCA-compliant OpenPGP profile "OSCCA-SM234".
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 https://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 May 31, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
SM2 [GBT.32918.1-2016] [I-D.shen-sm2-ecdsa], SM3 [GBT.32905-2016] [I-D.oscca-cfrg-sm3] and kM4 [GBT.32907-2016] [I-D.ribose-cfrg-sm4] are cryptographic standards issued by the Organization of State Commercial Cipher Administration of China [OSCCA] as authorized cryptographic algorithms for use within China. These algorithms are published in public.
Adoption of this document enables exchange of OpenPGP-secured email [RFC4880] in a OSCCA-compliant manner through usage of the authorized combination of SM2, SM3 and SM4.
SM2 is an elliptic curve cryptosystem (ECC) that is composed of a set of public key cryptographic algorithms based on elliptic curves and also a recommended elliptic curve:
SM3 [GBT.32905-2016] is a hash algorithm designed for electronic authentication purposes.
SM4 [GBT.32907-2016] is a symmetric encryption algorithm designed for data encryption.
SM2, SM3 and SM4 are standardized at ISO as [ISO.IEC.14888-3], [ISO.IEC.10118-3], and [ISO.IEC.18033-3.AMD2] respectively.
This document extends OpenPGP [RFC4880] and its ECC extension [RFC6637] to support SM2, SM3 and SM4:
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 [RFC2119].
Compliant applications are a subset of the broader set of OpenPGP applications described in [RFC4880]. Any [RFC2119] keyword within this document applies to compliant applications only.
The following terms and definitions apply to this document.
This document utilizes definitions of operations from [RFC7253] and are included here for reference.
SM2 is an elliptic curve based cryptosystem (ECC) [GBT.32918.1-2016] [I-D.shen-sm2-ecdsa] published by [OSCCA].
It was first published by the OSCCA in public in 2010 [OSCCA-SM2], then standardized as [GMT-0003-2012] in 2012, included in [ISO.IEC.11889] in 2015, published as a Chinese National Standard as [GBT.32918.1-2016], and published in [ISO.IEC.14888-3] in 2017.
The SM2 cryptosystem [I-D.shen-sm2-ecdsa] is published in 5 parts, covering:
Specifically, it is composed of three distinct algorithms:
This document refers to the SM2DSA and SM2PKE algorithms for the usage of OpenPGP [RFC4880].
[GMT-0009-2012] provides specifications on interoperable usage of SM2 data formats, and they are adhered to within within this document.
The SM2 Digital Signature Algorithm is intended for digital signature and verifications in commercial cryptographic applications, including, but not limited to:
The process of digital signature signing and verification along with their examples are found in [GBT.32918.2-2016], [ISO.IEC.14888-3], [SM2-2], and also described in [I-D.shen-sm2-ecdsa].
The SM2DSA process requires usage of a hash function within. For OSCCA-compliant usage, a OSCCA-compliant hash function such as SM3 [GBT.32905-2016] MUST also be used.
Formal security proofs for SM2 are provided in [SM2-SigSecurity] indicating that it satisfies both EUF-CMA security and security against generalized strong key substitution attacks.
The SM2DSA algorithm has been cryptanalyzed by multiple parties with the current strongest attack being nonce [SM2-DSA-Nonces] [SM2-DSA-Nonces2] and lattice attacks [SM2-DSA-Lattice].
In terms of OpenPGP usage, SM2DSA is an alternative to the ECDSA algorithm specified in [RFC6637].
For OpenPGP compatibility, these additional requirements MUST be adhered to:
The SM2 Key Exchange Protocol is used for cryptographic key exchange, allowing the negotiation and exchange of a session key within two to three message transfers.
The process of key exchange and verification along with their examples are found in [GBT.32918.3-2016] [SM2-3], and also described in [I-D.shen-sm2-ecdsa].
SM2KEP is not used with OpenPGP as it is a two- to three- pass key exchange mechanism, while in OpenPGP, public keys of recipients are available initially.
The SM2KEP is now considered insecure due to [SM2-KEP-Comments], similar in status to the Unified Model and MQV schemes described in [NIST.SP.800-56Ar2].
The SM2 Public Key Encryption algorithm is an elliptic curve based asymmetric encryption algorithm. It is used for cryptographic encryption and decryption, allowing the message sender to utilize the public key of the message receiver to encrypt the message, with the recipient decrypting the messaging using his private key.
The full description of SM2PKE is provided in [GBT.32918.4-2016].
It utilizes a public key size of 512 bits and private key size of 256 bits [GBT.32918.4-2016] [GMT-0003-2012].
The process of encryption and decryption, along with their examples are found in [GBT.32918.4-2016] and [SM2-4].
The SM2PKE process requires usage of a hash function within. For OSCCA-compliant usage, a OSCCA-compliant hash function such as SM3 [GBT.32905-2016] MUST also be used.
In OpenPGP, SM2PKE is an alternative to RSA specified in [RFC4880].
The recommended curve is specified in [GBT.32918.5-2017] [SM2-5] and provided here for reference. SM2 uses a 256-bit elliptic curve.
y^2 = x^3 + ax + b
p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
F39789F5 15AB8F92 DDBCBD41 4D940E93
n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
7203DF6B 21C6052B 53BBF409 39D54123
x_G = 32C4AE2C 1F198119 5F990446 6A39C994
8FE30BBF F2660BE1 715A4589 334C74C7
y_G = BC3736A2 F4F6779C 59BDCEE3 6B692153
D0A9877C C62A4740 02DF32E5 2139F0A0
[GMT-0009-2012] defines a number of data formats for the SM2 algorithm to allow interoperable implementations. This document adheres to these conventions.
SM2 secret key data format is described in ASN.1 as [GMT-0009-2012]:
SM2PrivateKey ::= INTEGER
SM2 public key data format is described in ASN.1 as [GMT-0009-2012]:
SM2PublicKey ::= BIT STRING
Where:
The SM2 encrypted data format is provided by [GMT-0009-2012] as the following in ASN.1 format:
SM2Cipher ::= SEQENCE{
XCoordinate INTEGER, -- x-coordinate
YCoordinate INTEGER, -- y-coordinate
HASH OCTET STRING SIZE(32), -- hash value
CipherText OCTET STRING -- ciphertext
}
Where:
SM2 signature data format is described in ASN.1 as [GMT-0009-2012]:
SM2Signature ::= SEQUENCE{
R INTEGER, -- first portion of signature
S INTEGER -- second portion of signature
}
R and S represent the first and second portion of the signature, and both are 256 bits long.
The SM3 Cryptographic Hash Algorithm [GBT.32905-2016] is an iterative hash function designed by Xiaoyun Wang et al., published by [OSCCA] as an alternative to SHA-2 [NIST.FIPS.180-4].
The specification, security considerations and cryptanalysis results of SM3 are thoroughly presented in [I-D.oscca-cfrg-sm3].
It was first published by the OSCCA in public in 2010 [SM3], then published as an industry cryptogrpahic standard in 2012 [GMT-0004-2012], published as a Chinese National Standard in 2016 as [GBT.32905-2016], and included in the [ISO.IEC.10118-3] standard in 2017.
The algorithm is designed to be used for commercial cryptographic applications including, but not limited to:
SM3 has a Merkle-Damgard construction and is similar to SHA-2 [NIST.FIPS.180-4] of the MD4 [RFC6150] family, with the addition of several strengthening features including a more complex step function and stronger message dependency than SHA-256 [SM3-Boomerang].
SM3 produces an output hash value of 256 bits long, based on 512-bit input message blocks [GBT.32905-2016], on input lengths up to 2^(m).
SM4 [GBT.32907-2016] is a symmetric encryption algorithm designed by Shuwang Lu et al. originally intended for the usage of wireless local area network (Wireless LAN) products.
The specification, security considerations and cryptanalysis results of SM4 are thoroughly presented in [I-D.ribose-cfrg-sm4] .
SM4 is a 128-bit blockcipher, uses a key size of 128 bits and internally uses an 8-bit S-box. It performs 32 rounds per block. Decryption is achieved by reversing the order of encryption.
SMS4 was first published in public as part of WAPI (Wired Authentication and Privacy Infrastructure), the Chinese National Standard for Wireless LAN [GB.15629.11-2003]. It was then published independently by the OSCCA in 2006 [SM4], formally renamed to SM4 in 2012 [GMT-0002-2012], published as a Chinese National Standard in 2016 [GBT.32907-2016], and included in [ISO.IEC.18033-3.AMD2] in 2017.
It is a required encryption algorithm specified in WAPI [GB.15629.11-2003].
The SM2 algorithm is supported with the following extension.
The following public key algorithm IDs are added to expand Section 9.1 of [RFC4880], "Public-Key Algorithms":
| ID | Description of Algorithm |
|---|---|
| TBD | SM2 |
Compliant applications MUST support both usages of SM2 Section 4:
The SM4 algorithm is supported with the following extension.
The following symmetric encryption algorithm ID is added to expand Section 9.2 of [RFC4880], "Symmetric-Key Algorithms":
| ID | Description of Algorithm |
|---|---|
| TBD | SM4 |
Compliant applications MUST support SM4 Section 6.
The SM3 algorithm is supported with the following extension.
The following symmetric encryption algorithm IDs are added to expand Section 9.3 of [RFC4880], "Hash Algorithms":
| ID | Description of Algorithm |
|---|---|
| TBD | SM3 |
Compliant applications MUST support SM3 Section 5.
The encoding method of [RFC6637] Section 6 MUST be used, and is compatible with the definition given in [SEC1].
For clarity, according to the EC curve MPI encoding method of [RFC6637], the exact size of the MPI payload for the "SM2 Recommended" 256-bit curve [GBT.32918.5-2017], is 515 bits.
A key derivation function (KDF) is necessary to implement EC encryption.
The SM2PKE KDF is defined in Section 3.4.3 of [GBT.32918.4-2016] (and Section 5.4.3 of [I-D.shen-sm2-ecdsa], Section 3.4.3 of [SM2-4]).
For OSCCA-compliance, it SHOULD be used in conjunction with an OSCCA-approved hash algorithm, such as SM3 [GBT.32905-2016].
The SM2PKE KDF is equivalent to the KDF2 function defined in Section 13.2 of [IEEE.1363a.2004] given the following assignments:
Pseudocode of the SM2KDF function is provided here for convenience. This function contains edited variable names for clarity.
K is defined as follows.
_____________________________________________________________________
Counter = 1 // a 32-bit counter
n = KEYLEN / v
for each 1 <= i <= Ceil(n)
Ha_i = Hash( Z || Counter )
Counter = Counter + 1
end for
if n is a whole number then
Ha! = Ha_{Ceil(n)}
else
Ha! = MSB(KEYLEN - (v x Floor(n)), Ha_{Ceil(n)})
end if
K = Ha_1 || Ha_2 || ... || Ha_{Ceil(n)-1} || Ha!
_____________________________________________________________________
The following algorithm-specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support SM2DSA and SM2PKE.
This document extends the algorithm-specific portion with the following fields.
Algorithm-Specific Fields for SM2DSA keys:
Algorithm-Specific Fields for SM2PKE keys:
Note that both SM2DSA and SM2PKE public keys are composed of the same sequence of fields, and use the same codepoint to identify them. They are distinguished by the key usage flags.
The following algorithm-specific packets are added to Section 5.5.3. of [RFC4880], "Secret-Key Packet Formats", to support SM2DSA and SM2PKE.
This document extends the algorithm-specific portion with the following fields.
Algorithm-Specific Fields for SM2DSA or SM2PKE secret keys:
Section 5.1 of [RFC4880], "Public-Key Encrypted Session Key Packets (Tag 1)" is extended to support SM2PKE using the following algorithm specific fields for SM2PKE, through applying the KDF described in Section 9.
Algorithm Specific Fields for SM2 encryption:
Section 5.2.2 of [RFC4880] defines the signature format for "Version 3 Signature Packet Format". Similar to ECDSA [RFC6637], no change in the format is necessary for SM2DSA.
Section 5.2.3 of [RFC4880] defines the signature format for "Version 4 Signature Packet Format". Similar to ECDSA [RFC6637], no change in the format is necessary for SM2DSA.
This section provides the curve ASN.1 Object Identifier (OID) of the "SM2 Recommended Curve" [GBT.32918.5-2017] described in Section 4, according to the method of [RFC6637].
We specify the curve OID of the "SM2 Recommended Curve" to be the registered OID entry of "SM2 Elliptic Curve Cryptography" according to [GMT-0006-2012], which is "1.2.156.10197.1.301".
The table below specifies the exact sequence of bytes of the mentioned curve:
| ASN.1 OID | OID len | Curve OID bytes in hex | Curve name |
|---|---|---|---|
| 1.2.156.10197.1.301 | 8 | 2A 81 1C CF 55 01 82 2D | SM2 Recommended |
The complete ASN.1 DER encoding for the SM2 Recommended curve OID is "06 08 2A 81 1C CF 55 01 82 2D", from which the first entry in the table above is constructed by omitting the first two octets. Only the truncated sequence of octets is the valid representation of a curve OID.
The "OSCCA SM234" profile is designed to be compliant to OSCCA regulations. A compliant OpenPGP implementation MUST implement the following items as described by this document:
The IANA "Pretty Good Privacy (PGP)" registry [RFC8126] has made the following assignments for algorithms described in this document, namely:
This example is generated using the OpenPGP implementation RNP [RNP], with the SM2 and SM3 implementations from Botan [BOTAN].
-----BEGIN PGP PUBLIC KEY BLOCK----- xlIEWbGKWmMIKoEcz1UBgi0CAwQx5lUJNwGp01AB7YfAye0oMmyIPYe/cQPVwh8/7RCu ywZLMDDAM7qn6TNqTtdKW+7tLFhtOC4yzDVK8UjN/ccazSBTTTIgMjU2LWJpdCBrZXkg PGphY2tAbG9jYWxob3N0PsJ0BBNjaQAmBQJZsYpfAhsDBQsJCAcCBhUICQoLAgUWAgMB AAkQC/UcNw0bAZcAAJt5AP4oXvi3xl2RUwAvVjlzXtLL87g6x9cIBS7EB/cvAsw78AEA /Wt6qWlBVZ6TYiqNPt9An/4cjKyNpAv7S9u3neGXWUU= =RJ3C -----END PGP PUBLIC KEY BLOCK-----
This example is also created using RNP [RNP] and Botan [BOTAN].
Detached signature of the string "SM2 example" using the above key:
-----BEGIN PGP SIGNATURE----- wmQEAGMIABYFAlmxj+cFAwAAAAAJEAv1HDcNGwGXAAB+SQEAy5AHKgiRxgOogB/2sfge JaVoLgpxvDp9yIcaLfP++xkBAPGuZ1f9FjxVd5jlCGd1jFzAPpt8N2Lc3FQDqVjgJvV9 =Xbbj -----END PGP SIGNATURE-----
The authors would like to thank the following persons for their valuable advice and input.