Opacity Secure Channel: Globalplatform Card - Amendment G
Opacity Secure Channel: Globalplatform Card - Amendment G
Opacity Secure Channel: Globalplatform Card - Amendment G
Public Release
October 2016
Document Reference: GPC_SPE_106
THIS SPECIFICATION OR OTHER WORK PRODUCT IS BEING OFFERED WITHOUT ANY WARRANTY
WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLY
DISCLAIMED. ANY IMPLEMENTATION OF THIS SPECIFICATION OR OTHER WORK PRODUCT SHALL
BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER THE COMPANY, NOR ANY
OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY
IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER DIRECTLY
OR INDIRECTLY ARISING FROM THE IMPLEMENTATION OF THIS SPECIFICATION OR OTHER
WORK PRODUCT.
Contents
1 Introduction ............................................................................................................................ 7
1.1 Audience ...............................................................................................................................................7
1.2 IPR Disclaimer ......................................................................................................................................7
1.3 References ............................................................................................................................................7
1.4 Terminology and Definitions .................................................................................................................9
1.5 Abbreviations and Notations ...............................................................................................................10
1.6 Revision History ..................................................................................................................................11
2 Use Cases ............................................................................................................................. 12
3 Algorithms ............................................................................................................................ 14
3.1 ECC .....................................................................................................................................................14
3.1.1 EC Curves ....................................................................................................................................14
3.1.2 Random Number Generators .......................................................................................................14
3.1.3 EC Private Key .............................................................................................................................15
3.1.4 EC Points .....................................................................................................................................15
3.1.5 EC Public Key ..............................................................................................................................15
3.1.6 EC Public Key Blinding ................................................................................................................15
3.1.7 ECDSA .........................................................................................................................................15
3.2 Certificates ..........................................................................................................................................16
3.2.1 Certificate Types ..........................................................................................................................16
3.2.2 Trusted Certificates ......................................................................................................................16
3.2.3 Certificate Chains .........................................................................................................................16
3.2.4 CVC Format (Informative) ............................................................................................................17
3.2.5 Certificate Validation ....................................................................................................................19
3.3 Key Derivation .....................................................................................................................................20
3.3.1 2-Step Key Derivation Function (KDF2S) ....................................................................................20
3.3.2 1-step Key Derivation Function (KDF1S) .....................................................................................22
3.4 Authenticated Encryption ....................................................................................................................23
3.4.1 Authenticated Encryption with Associated Data (AEAD) .............................................................23
3.4.2 Authenticated Encryption without Associated Data (AE) .............................................................23
3.4.3 AEAD Modes ................................................................................................................................23
3.4.4 Block Cipher .................................................................................................................................23
4 Protocol................................................................................................................................. 24
4.1 Cipher Suites .......................................................................................................................................24
4.2 Protocol Parameters ...........................................................................................................................27
4.3 Protocol Flow ......................................................................................................................................30
4.3.1 Principle .......................................................................................................................................30
4.3.2 Protocol Steps ..............................................................................................................................31
4.4 Protocol Parameter Negotiation ..........................................................................................................37
4.4.1 Host Cipher Suite List ..................................................................................................................37
4.4.2 SE Cipher Suite Selection ............................................................................................................37
4.4.3 Certificate Format .........................................................................................................................37
4.4.4 SE Key Reference ........................................................................................................................37
4.4.5 SE Response Parameters............................................................................................................37
4.4.6 Protocol Cases .............................................................................................................................38
4.5 Secure Messaging ..............................................................................................................................39
5 Parameter Encoding............................................................................................................. 40
5.1 Control Byte Encoding ........................................................................................................................40
Figures
Figure 2-1: Opacity Blinded Protocol Overview ...............................................................................................13
Figure 3-1: Extraction-then-Expansion Key Derivation Procedure ..................................................................20
Figure 4-1: Protocol Flow Overview ................................................................................................................30
Tables
Table 1-1: Normative References ......................................................................................................................7
Table 1-2: Informative References ....................................................................................................................9
Table 1-3: Abbreviations and Notations ..........................................................................................................10
Table 1-4: Revision History .............................................................................................................................11
Table 3-1: ECC Key Length and Recommended Curves ...............................................................................14
Table 3-2: Hash Algorithms for ECDSA ..........................................................................................................15
Table 3-3: Card Verifiable Certificate Format ..................................................................................................17
Table 3-4: KDF Configuration Based on Input Curve ......................................................................................22
Table 3-5: Available AEAD Modes ..................................................................................................................23
Table 4-1: Requirements for Opacity Cipher Suites ........................................................................................24
Table 4-2: Opacity Blinded Protocol Cipher Suites .........................................................................................26
Table 4-3: Opacity-ZKM Mode Cipher Suites ..................................................................................................26
Table 4-4: Opacity-FS Mode Cipher Suites .....................................................................................................26
Table 4-5: Protocol Parameters .......................................................................................................................27
Table 4-6: Protocol Steps – Host Prerequisites ..............................................................................................31
Table 4-7: Protocol Steps – SE Prerequisites .................................................................................................32
Table 4-8: Protocol Steps – Host Request ......................................................................................................32
Table 4-9: Protocol Steps – SE Response ......................................................................................................32
Table 4-10: Protocol Steps – Host Validation ..................................................................................................35
Table 5-1: Control Byte Encoding....................................................................................................................40
Table 5-2: Cipher Suite Encoding – Curve Byte ..............................................................................................41
Table 5-3: Cipher Suite Encoding – Cipher Byte .............................................................................................42
Table 5-4: Cert Format Byte ............................................................................................................................42
Table 5-5: Key Reference ................................................................................................................................43
Table 6-1: Command Data ..............................................................................................................................44
Table 6-2: Response Data ...............................................................................................................................44
Table 6-3: GENERAL AUTHENTICATE Command Message ........................................................................45
Table 6-4: GENERAL AUTHENTICATE Error Conditions ..............................................................................46
Table 7-1: SCP Information .............................................................................................................................49
Table 8-1: Key and Certificate Requirements .................................................................................................50
1 Introduction
The purpose of this amendment is to extend the GlobalPlatform Card Specification [GPCS] with new secure
channel and key establishment protocols, altogether known as the Opacity Secure Channel establishment
method or Secure Channel Protocol '22'.
The Opacity Secure Channel establishment method includes:
Opacity ZKM and Opacity FS protocols as defined in [ANSI 504-1]
Opacity Blinded protocol as defined in this specification
Configurations will define the protocol modes, the selection of cipher suites and secure messaging formats
that are mandatory or optional in specific market segments.
1.1 Audience
This amendment is intended primarily for card manufacturers and developers of applications for
GlobalPlatform cards.
It is assumed that the reader is familiar with smart cards and smart card production, and in particular familiar
with the GlobalPlatform Card Specification [GPCS].
1.3 References
Table 1-1: Normative References
2 Use Cases
The purpose of this specification is to present and specify a compact and efficient method to establish secure
channel keys between an entity (Host) and a secure element that can be authenticated using a public/private
elliptic curve key pair. The secure channel keys are established in a single request response step, and can be
used to protect further communication between the SE and Host (host or terminal).
See [ANSI 504-1] and [NIST 800-73-4] Part II section 4.1 for specific use cases involving Opacity ZKM mode
and Opacity FS mode.
The supplementary Secure Channel establishment method presented in this specification, i.e. the Opacity
Blinded protocol, allows correct implementations to make the following security claims:
One-way entity authentication – The identity claimed in the response message from the SE can be
proven to be bound to the SE secret.
One-way messaging privacy – The identity of the SE is carried in the response but not revealed.
One-way message authentication – The response message from the SE can be proven to be bound
to the SE secret.
Non-traceability – The information from two messages cannot be correlated to reveal the message
origin, or to reveal the message content.
Forward Secrecy – The compromise of the long term SE secret does not compromise the message
privacy or confidentiality of any payload sent in the past.
The privacy and non-traceability properties claimed above depend on the initial assumption that the host is not
an active attacker, and would not be valid otherwise. Host Authentication may be performed at the application
level using the secure messaging resulting from the execution of the protocol.
A formal analysis to prove the above security properties has been established in ‘An analysis of the EMV
channel establishment protocol’ ([Smart]). The proofs on privacy, non-traceability, and forward secrecy
assume that a full size blinding factor is being used, i.e., the blinding factor shall have the same number of bits
as the curve order.
Using standard-based cryptography in [GPCS]:
The messaging specification allows a mapping to APDUs or other communication channels.
3 Algorithms
3.1 ECC
3.1.1 EC Curves
Elliptic Curve Cryptography over prime fields GF(p) shall be used for the purpose of this amendment.
Standardized Domain Parameters are recommended to be used:
Digital Signature Standard (DSS) [FIPS 186-4], recommended by NIST, or
Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation [RFC 5639],
recommended by BSI.
These references specify the EC domain parameters for curves of different key lengths:
P: Prime field specification parameter
A,B: EC curve equation parameters
G: Base EC Point
N: EC order parameter
k: EC cofactor parameter
The following table lists recommended curves for different ECC key lengths.
Recommendations for appropriate random number generators are given in BSI TR-02102 [TR 02102] and
NIST SP 800-90A [NIST 800-90A].
The random number generator involves an entropy source and a Pseudo Random Number Generator (PRNG)
applied on the source output. Example PRNGs are defined in [NIST 800-90A]:
CTR-DRBG (Block cipher based PRNG)
HMAC-DRBG or Hash_DRBG (Hash-based PRNG)
A private key is a randomly generated number with the size of the EC Key Length in bits. A recommended
number generator must be used (see section 3.1.2).
3.1.4 EC Points
Any point Q on the curve with x- and y-coordinates (x,y) shall be encoded either as:
In [TR 03111] section 3.2.
An optimized encoding, i.e. the byte string representation of the x-coordinate only. The y-coordinate is
chosen as the lowest value obtained by applying the curve equation to the x-coordinate.
The multiplication of any point (x, y) on the curve with an integer number is another point on the curve (x', y').
The multiplication of the base point G with a private key d is the associated public key.
The multiplication of any EC Public Key with a random blinding factor, which size in bits is comprised between
n and n/2 where n is the number of bits the EC curve order N.
3.1.7 ECDSA
The signature shall be coded according to the signed object format (see section 3.2.4). The ECDSA signature
algorithm requires a random value as input. To protect against attacks, a high quality random number
generator is required for the entity generating the signature. Recommendations for appropriate random
number generators are given in section 3.1.2.
3.2 Certificates
3.2.1 Certificate Types
X.509 v3 and Card Verifiable Certificates (CVC) in section 3.2.4 are the two certificate types recommended in
this version of the specification.
Any entity validating that a certificate can be trusted must first trust the corresponding signing certificate.
A validating entity must therefore trust the original signing certificates such as root certificates or CA certificates
or at least trust the public key association with the issuer, root, or CA identity. The process allowing an entity
to trust an issuer, root, or CA certificate or its public key association is outside the scope of this specification.
Certificates for which signing certificates are not already trusted by the validating entity may be presented
instead as certificate chains, i.e. a sequence of certificates. Each certificate in the sequence is the signing
certificate for the following certificate in the chain. The first certificate must be verifiable by the validating entity.
The Card Verifiable Certificate Format used in this specification follows [ISO 7816-8] and [ANSI 504-1] as
follows:
Where:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm
OPTIONAL
}
This section describes the 2-step Key Derivation Function (KDF2S), also specified in [NIST 800-56C], and
makes appropriate choices for Opacity.
Extraction Step
The extraction-then-expansion key derivation procedure begins with a shared secret Z. Z is the x-coordinate
of the common EC point computed on both sides.
Z length in bytes is defined according to the following rule:
Len (Z) is equal to the lowest number of bytes that can include a number of bits equal to the EC curve
order.
Example:
For P-256 or brainpoolP256r1: len(Z) = 256/8 = 32 bytes
For P-521: len(Z) = 521/8 = 65.125. The lowest number of bytes to include the curve order in bits is 66
bytes.
The Randomness Extraction function is the MAC function (AES-CMAC).
s – Salt, a (public or secret) byte string used as the “key” during the execution of the randomness extraction
step. s is the all-zero byte string. The bit length of the all-zero byte string shall equal the length of the AES
key used, e.g. for AES 128:
s = '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'
KDK – The output of the randomness extraction step.
When AES-CMAC is used, KDK is a binary string of length 128 bits.
1. KDK = AES-CMAC (s, Z)
2. Zeroize Z.
Expansion Step
This section describes the Key Derivation Function (KDF) common to all session keys regardless of the method
used to generate the shared secret.
The expansion step is as specified in NIST SP 800-108 [NIST 800-108] in counter mode (§5.1). It takes as
input the result of the extraction step KDK, the total session key data length ‘len’, and supplementary data
‘OtherInput’ consisting of multiple data elements A1, .. , Am, and produces session keys as follows:
OtherInput (A1, .. , Am) = [AlgorithmID(SK1) || .. || AlgorithmID(SKp) || A1 || .. || Am]
len = algoKeyLengthInBits(SK1) + … + algoKeyLengthInBits(SKp)
n = len / (hashLengthInBits (KDFHashAlgorithm)) = len/128
KM = [AES-CMAC (KDK, '00 00 00 01' || OtherInput) || AES-CMAC (KDK, '00 00 00 02' || OtherInput) || … ||
AES-CMAC (KDK, ('00 00 00 00' + n || OtherInput)]
With:
The concatenated session keys (SK1 || .. || SKp ) are the (len) leftmost bits from KM.
This section describes the 1-step Key Derivation Function (KDF1S), which is based on the use of the shared
secret previously exchanged using public key cryptography. It is common to all session keys regardless of the
method used to generate the shared secret.
The Key Derivation Function is implemented as specified in [NIST 800-56A] §5.8.1. It takes as input a shared
secret ‘Z’, total session key data length ‘len’, and supplementary data ‘info’, and produces session keys as
follows:
The concatenated session keys (SK1 || .. || SKp ) are the (len) leftmost bits from DerivedKeyingMaterial.
With:
len = algoKeyLengthInBits(SK1) + … + algoKeyLengthInBits(SKp)
DerivedKeyingMaterial = [KDFHashAlgorithm('00 00 00 01' || Z || info) || KDFHashAlgorithm('00 00 00 02'
|| Z || info) || KDFHashAlgorithm(('00 00 00 00' + n ) || Z || info)]
With:
KDFHashAlgorithm = SHA-256 or SHA-384 or SHA-512 (See Table 3-5 below.)
n = len / (hashLengthInBits (KDFHashAlgorithm))
Z = Shared Secret
Info (A1, .. , Am) = [AlgorithmID(SK1) || .. || AlgorithmID(SKp) || A1|| .. || Am]
With:
The Authenticated encryption modes defined in section 3.4.3 allow the protection of data for confidentiality and
integrity as follows:
AEAD (SK, AD, PT) = AD || CT || MAC
Where:
SK = Session Key
AD = Associated Data. Will not be encrypted.
PT = Plain text. Will be encrypted.
CT = Cipher Text resulting from encryption of PT with SK
MAC = Integrity check value using SK computed over the concatenation of AD (clear text) and CT (cipher
text).
Mode Reference
OCB2 See [ISO 19772] section 6.
CCM See [ISO 19772] section 8.
EAX See [ISO 19772] section 9.
Encrypt then MAC See [ISO 19772] section 10.
(ETM-CTR-CMAC) Use AES Counter Mode encryption and AES-CMAC.
GCM See [ISO 19772] section 11.
4 Protocol
This chapter specifies the Opacity Blinded protocol. The protocol for Opacity ZKM and Opacity FS are specified
in [ANSI 504-1].
In this specification, Cipher Suites are defined for the Opacity protocol and are assigned a UTF-8 string name
according to the following pattern:
OPACITY-{bit_strength}-{key_agreement_mode}-{curve_type}-
{key_derivation_function}-{AEAD_mode}-{secure_messaging_mode}
Where :
Bit_strength
o 128, 192, or 256.
key_agreement_mode
o ECDHB : usage of Elliptic Curve Diffie-Hellman Blinded Mode (as described in this document).
curve_type
o NIST means usage of the NIST curve according to the specified bit strength (e.g. P256 for
Opacity-128).
o BR1 means usage of the Brainpool r1 curve according to the specified bit strength (e.g.
brainpoolP256r1 for Opacity-128).
o SM2 means usage of the SM2 curve according to the specified bit strength (e.g. SM2 Fp-256 for
Opacity-128).
key_derivation_function
o KDF1S: one–step KDF
o KDF2S: two–step KDF
AEAD_mode
o CCM, GCM, and ETM are the recommended AEAD modes necessary to compute the response
of the authentication command. The selection also applies to the AEAD secure messaging mode
when it is selected.
secure_messaging_mode
o AEAD means usage of AEAD secure messaging. The AEAD mode used to protect the response to
the authentication command message and for the AEAD secure messaging shall be the same.
o SCP03 means usage of SCP03 secure messaging. When SCP03 is selected AEAD is still
necessary to protect the response of the authentication command message.
The Ciphers Suites defined by this specification are listed in Table 4-2. Each Cipher Suite is assigned a 2-byte
identifier for reference in environments where UTF-8 strings cannot be used.
P1 byte
Cipher Suites 2-byte Identifier
[ANSI 504-1] Table 91
OPACITY_128_ECDH_NIST_KDF1S_SCP03 (used in '01 04' '27'
[NIST 800-73-4])
OPACITY_192_ECDH_NIST_KDF1S_SCP03 (used in '02 04' '2B'
[NIST 800-73-4])
P1 byte
Cipher Suites 2-byte Identifier
[ANSI 504-1] Table 91
OPACITY_128_ECDH_NIST_KDF1S_SCP03 '01 04' '28'
OPACITY_256_ECDH_NIST_KDF1S_SCP03 '02 04' '2D'
The Opacity Protocol consists of three required steps, followed by optional steps to exchange messages within
the secure channel that is established.
1. Host Request: Host prepares and sends Command (i.e. Authentication Request) to SE
2. SE Response: SE receives and processes Command, prepares and sends Response to Host
3. Host Validation: Host receives and processes Response, authenticating SE and decrypting SE
response payload
4. <Optional secure channel messages>
The Opacity Blinded protocol is completed and a secure channel is established. Use secure messaging with
SK_h to protect additional commands and SK_se to decrypt and authenticate the responses (see
section 6.2.3).
The host provides a mandatory cipher suite list in the command that informs the SE about the combinations
of curve, secure messaging mode, KDF, and AEAD mode which can be accepted (see section 4.1). The first
element of the host cipher suite list is the default cipher suite. The host ephemeral public key shall be on the
default cipher suite curve.
The SE must select one cipher suite of the host cipher suite list to successfully complete the protocol execution.
If the SE application policy allows the use of the default cipher suite, then the SE should select it. However the
appropriate selection of cipher suite and key reference is determined per SE application policy. If no cipher
suite is supported or allowed from the host list, or if the SE does not support the default Curve and default
KDF, then the SE will return an error with no further information.
The SE must support the default cipher suite curve and the default cipher suite KDF, to allow the protection of
SE protocol parameters in the response. The SE Application policy may forbid to return identity data such as
certificates or application payload data with the default curve. In that case the SE will indicate in a first response
protected by the default curve, which other – non-default – cipher suite supported by the host shall be used to
obtain the desired identity or application data.
The host provides a certificate format byte (CF_h) in the command that informs the SE about all certificate
formats that the host allows for authentication. The SE shall return a certificate having a format that the host
indicates in the command. Otherwise it returns an error with no further information.
The host provides a SE key reference (KR_h) in the command that informs the SE about what private key
should be used (d_se). KR_h shall refer to a key that belongs to the default cipher suite. The SE should use
this key (i.e. KR_se = KR_h) if allowed by the SE application policy, if the SE has the private key corresponding
to the proposed SE key reference (KR_h), and if the host default curve is the curve for KR_se.
To inform the host about the selected cipher suite and key reference, and protect this information from
eavesdropping, the SE must encrypt this information in the response and shall use the default cipher suite
curve and KDF for that matter. Section 4.4.6 details the different protocol cases.
In that case the SE may choose the private key (d_se) corresponding to the host key reference (KR_h) or a
different private key for the same default cipher suite curve. The SE will indicate the chosen key reference in
the response (KR_se). The SE uses all default cipher suite parameters, KDF, and AEAD mode, to produce
the session key and protect the response information including the selected key agreement parameters, in
that case the default cipher suite and selected key reference, the blinding factor, and the certificate.
4.4.6.2 Case 2 – SE supports default curve and KDF, but requires another suite in list
If the non-default cipher suite is compatible with the default suite (same curve and KDF), but with a different
AEAD mode or secure messaging then the response may be fully protected with the non-default cipher suite.
If the non-default cipher suite has an incompatible curve or incompatible KDF with the default cipher suite, the
protocol must be restarted with appropriate key agreement parameters selected by the SE.
The SE will generate an ephemeral key pair on the default curve, and use the default cipher suite to protect
the response. The response will contain the SE ephemeral public key protected SE Key Agreement
Parameters, but no certificate, blinding information, or SE application payload.
The host will decrypt the response to determine the selected cipher suite and key reference. It will check that
the SE cipher suite selection is included in the cipher suite list and will resubmit a command with appropriate
SE cipher suite, including a new ephemeral host public key. The host cipher suite list and default cipher suite
must remain unchanged as the selected SE cipher suite must not be revealed.
4.4.6.3 Case 3 – SE supports default curve but does not allow any cipher suite in list
The SE is not able to protect its application payload using the host capabilities. It shall return an error.
The SE is not able to protect its cipher suite selection in a response. It shall return an error.
5 Parameter Encoding
This chapter describes the encoding for the Opacity Blinded protocol parameters. The encoding of Opacity
ZKM and Opacity FS parameters is specified in [ANSI 504-1].
b8 b7 b6 b5 b4 b3 b2 b1 CB Encoding Description
(RFU) (*)
0 – – 1 0 0 0 0 CS_CHANGE Cipher suite must be
changed
0 – 1 0 0 0 0 0 BLIND Blind Mode requested
0 0 0 0 0 0 – – ZKM (*) ZKM mode requested
0 1 0 0 0 0 – – FS (*) Full Secrecy Mode
requested
1 0 0 0 0 0 0 0 ERROR Error occurred
Description Value
Reserved '00', 'FF'
Proprietary '80' – 'FE' (range)
NIST P256 '01'
NIST P384 '02'
NIST P521 '03'
Brainpool 256r1 '04'
Brainpool 384r1 '05'
Brainpool 512r1 '06'
Brainpool 256t1 '07'
Brainpool 384t1 '08'
Brainpool 512t1 '09'
SM2 Fp-256 '0A'
RFU '0B' – '7F' (range)
– – – – 0 0 0 1 CVC encoding
– – – – 0 0 1 0 X.509 encoding
– – X X – – – – EC Point Representation
– – 0 0 – – – – As defined in [TR 03111] section 3.2
– – 0 1 – – – – Optimized. See section 3.1.4
Description Value
Reserved '00', '80' – 'FF'
Application Specific '01' – '7F'
6 Messaging
6.1 Message Flow
The message flow for all Opacity protocols (ZKM, FS, and Blinded) consists of a first command message
transmitted by a sender entity (host) to a responder entity (Secure Element). This is followed by a response
message transmitted from the responder to the sender. Secure channel key establishment is completed at this
point, so any number of protected messages may be transmitted both ways (see Figure 2-1).
This section applies to the Opacity Blinded protocol only. Transport for Opacity ZKM and FS protocols is
specified in [ANSI 504-1].
The GENERAL AUTHENTICATE command defined in [ISO 7816-4] is used to transport the Opacity command
message and the Opacity response message between the card and the host.
This command also initiates an optional Secure Channel Session.
At any time during a current Secure Channel, the GENERAL AUTHENTICATE command can be issued to the
card in order to initiate a new Secure Channel Session.
The GENERAL AUTHENTICATE command message is coded according to the following table:
This value should be set to '00'. If not '00' it must match the default recommended host cipher suite, i.e. the
leftmost byte of CSL_h in command data.
The Key Reference should be '00'. If non zero, it must be set to KR_h.
The data field of the response message shall be as specified in section 6.2.1.2.
A successful execution of the command shall be indicated by status bytes '90' '00'. This command may either
return a general error condition as listed in [GPCS] section 11.1.3 or the following error conditions:
The secure messaging for Opacity ZKM and Opacity FS protocols is specified in [ANSI 504-1].
The following sections define secure messaging mechanisms and format for the Opacity Blinded protocol.
6.2.3.1 AEAD
The AEAD scheme referenced in the cipher suite is used to further protect the host commands and SE
responses.
The APDU protection may leverage AEAD using AE modes defined in section 3.4.3 as follows:
AD = APDU Header = (CLA || INS || P1 || P2)
PT_c = APDU command Payload (including TLV)
CT_c = Encrypted command payload
C-APDU = AD || PT_c
MAC_c = command MAC (defined from AEAD mode)
PT_r = APDU response Payload (including TLV)
CT_r = Encrypted response payload
MAC_r = response MAC (defined from AEAD mode)
SW = SW1 || SW2
R-APDU = PT_r || SW
Note: Certain AEAD modes (AEAD-CCM) require the Initialization Vector (IV) to be updated each time the
same session key is reused (for instance a counter must be used as IV).
6.2.3.2 AE
The Authenticated Encryption (AE) Secure messaging scheme is identical to AEAD Secure Messaging (see
section 6.2.3.1), with the following condition:
AD = NULL
SW = NULL
6.2.3.3 SCP03
SCP03 secure messaging mechanism and format is described in [GPCS-D]. Also see section 4.5 for SCP03
key establishment with Opacity.
If the SM2 curve is used, SMS4 block cipher shall be used instead of AES in the SCP03 protocol.
SCP03 ISO secure messaging mechanism and format is described in [GPCS-ISO]. Also see section 4.5 for
SCP03 ISO key establishment with Opacity.
If the SM2 curve is used, SMS4 block cipher shall be used instead of AES in the SCP03 ISO protocol.
Non APDU schemes may be defined to transport Opacity messages if they preserve the overall framework
and message flow but are outside the scope of this specification.
APDU commands that are not specified within [ISO 7816-4] may be defined to transport Opacity messages if
they preserve the overall framework and message flow but are outside the scope of this specification.
The new ‘Supported cipher suites for SCP22’ TLV shall be used to describe the SCP22 cipher suites supported
by the implementation and contains a sequence of supported cipher suite numbers as defined in Table 4-2.