1. The devil is in the details
Migration strategies for cryptographic algorithms (Migration to quantum-safe algorithms)
Erik Andersen
Andersen's L-Service
Member of the Danish TC57 committee & WG15
Member of ITU-T Study Group 17, Question 11

2. Interworking issue
When moving to new cryptographic algorithms not everybody will move at the same time (no big bang)
Will potentially create interworking problems
Solution: During a migration period duplicate the cryptographic algorithm(s)

3. The strategy
At the start of the migration period, two cryptographic algorithms of a particular type are allowed to be included in specific way
The native algorithm used before start of migration period together with associated information
An alternative, assumingly stronger algorithm together with associated information
An advanced entity will include both algorithms
A back level entity will include only the native algorithm

4. The strategy (Cont.)
The alternative algorithm and associated information shall be specified in such a way that a back level recipient can ignored it
A back level recipient will ignore the alternative algorithm, but validate according to the native one
An advanced recipient will validate according to the alternative algorithm
At the end of the migration period, the alternative algorithm becomes the new native algorithm

5. Two different cases X.509 data types with extension mechanism:
Public-key certificates
Attribute certificates
Certificate Revocation Lists (CRLs)
Authorization and Validation Lists (AVLs)
Communications protocols

6. Extension characteristics
A supported extension shall be processed
An unsupported non-critical extension shall be ignored
These characteristics are utilized for migration purposes

7. Public-key certificate
Version
Serial Number
Issuer signature algorithm
Extension 1
Issuer
Extension 2
Validity
Subject
Alternative Signature algorithm
Subject’s public key info
Issuer Unique Id
Alternative subject’s public key info
Subject Unique Id
Alternative Signature
Extensions
Signature algorithm
Signature
Extension n

8. Protocol migration considerations
When cryptographic algorithms may be negotiated before its use
When cryptographic algorithms cannot be negotiated before its use
Special considerations for new protocols
Special considerations existing protocols
Special considerations whether ASN.1 extension marks are supported or not
Special considerations for digital signatures

9. Use or non-use of handshake
A formal handshake exchange before the data transfer phase allows:
Cryptographic algorithms not used during the handshake can be negotiated.
Cryptographic algorithms used during the handshake require special measures for migration.
Non-use of handshake requires special measures for all used cryptographic algorithms

10. Negotiation mechanism during handshake
A sending entity provides a sequence of cryptographic algorithm alternatives in a handshake request
The recipient shall take the first top one it supports to be included in the handshake accept
During the migration period:
The sender puts the alternative cryptographic algorithm at the top and the native cryptographic algorithm as number two
If the recipient supports the alternative algorithm, that is returned in the accept. Otherwise, it takes the second alternative.
Should be clearly specified in the English text

11. Where negotiation not possible
Protocols without handshake
Cryptographic algorithms used during the handshake

12. Adding alternative algorithm to existing association request when extension marks are used
Before:
HandshakeReq ::= SEQUENCE {
- - -
crypt AlgorithmIdentifier{{SupportedSymmetricKeyAlgorithms}},
... }
After:
HandshakeReq ::= SEQUENCE {
- - -
crypt AlgorithmIdentifier{{SupportedSymmetricKeyAlgorithms}},
...,
altCrypt AlgorithmIdentifier{{SupportedSymmetricKeyAlgorithms}} }

13. Adding alternative algorithm to existing association request when extension marks are not used
The parameter field of an algorithm specifications may be any data type. This allows for defining multiple algorithms within a single algorithm specification
multipleSignaturesAlgo ALGORITHM ::= {
PARMS MultipleSignaturesAlgo
IDENTIFIED BY id-algo-multipleEncryptionAlgo }
MultipleSignaturesAlgo ::= SEQUENCE SIZE (1..MAX) OF
algo SEQUENCE {
algorithm ALGORITHM.&id({SupportedSignatureAlgorithms}),
parameter OPTIONAL,
... }
Pro: No change to the specification
Con: Change to implementations
The necessary specification, including object identifiers, are defined in Rec. ITU-T X.510 | IEC

14. Signature on Application Protocol Data Unit (APDU)
Protected by signature
Signature algorithm
ToBeSigned
Signature algorithm
Signature
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier AlgorithmIdentifier{{SupportedAlgorithms}},
signature BIT STRING,
... }

15. Alt. Signature on APDU for new protocols
Protected by signature
Signature algorithm
Ignore if algorithm not supported
Alt. signature algorithm
ToBeSigned
Signature algorithm
Extension mark
Signature
Extended SIGNED data type
Alt. signature algorithm
Optional - to be ignored if algorithm not supported
Alt. Signature
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier AlgorithmIdentifier{{SupportedAlgorithms}},
signature BIT STRING,
...,
altAlgorithmIdentifier AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,
altSignature BIT STRING OPTIONAL }

16. Alt. Signature on Application Protocol Data Unit (APDU) - 2
Request:
---
sigAlg AlgorithmIdentifier {{SupportedSignatureAlgorithms}},
altSigAlg [0] AlgorithmIdentifier {{SupportedSignatureAlgorithms}} OPTIONAL,
Response:
---
sigSel CHOICE {
sigAlg AlgorithmIdentifier {{SupportedSignatureAlgorithms}},
altSigAlg [0] AlgorithmIdentifier {{SupportedSignatureAlgorithms}} },
The responder is able to indicate that it has migrated, which might be used in subsequent communications

17. Alt. Signature on APDU for an existing protocols with extension marks supported
Protected by signature
Signature algorithm
ToBeSigned
Protected by signature
Alt. signature algorithm
Signature algorithm
Extension marks
Signature
Extended SIGNED data type
Alt. signature algorithm
Optional - to be ignored
Alt. Signature
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier AlgorithmIdentifier{{SupportedAlgorithms}},
signature BIT STRING,
...,
altAlgorithmIdentifier AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,
altSignature BIT STRING OPTIONAL }

18. Protection during data transfer phase
For performance reasons, data transfer APDUs are typically not protected by digital signatures, but by so-called Message Authentication Code (MAC).
A MAC is also called an Integrity Check Value (ICV). This term is used here

19. An ICV data type corresponding to SIGNED data type
ICV{ToBeProtected} ::= SEQUENCE {
toBeProtected ToBeProtected,
nonce OCTET STRING OPTIONAL,
algorithmIdentifier AlgorithmIdentifier{{SupportedIcvAlgorithms}},
icv OCTET STRING,
altAlgorithmIdentifier AlgorithmIdentifier{{SupportedIcvAlgorithms}} OPTIONAL,
altIcv OCTET STRING OPTIONAL,
... }
Only necessary if ICV algorithm not negotiated during handshake
Defined in Rec. ITU-T X.510 | ISO/IEC

20. Outstanding issue Two entities need to share symmetric keys
For encryption
For generation and validation of ICVs
Such keys need to be established in some way
How to migrate current methods are presently not clear!

21. Methods for establishing symmetric keys between two entities
Key distribution - not scalable
Key transport (key encryption) - RSA dependent
Key agreement, e.g., Diffie-Hellman
Results in a shared secret
One or more symmetric key generated from shared secret using some algorithm, e.g., HMAC-based Extract-and- Expand Key Derivation Function (HKDF) (RFC 5869)
Currently used by IEC and X.510

22. Methods for establishing symmetric keys between two entities
What are the future symmetric key establishment algorithms?
Some kind of "Diffie-Hellman" techniques
Key encapsulation methods, e.g., QC-MDPC (Quasi Cyclic - Moderate Density Parity Check)
Difficult to make a migration strategy without knowing where to go

23. Key encapsulation method (KEM)
Key encapsulation different from key encryption (using RSA)
Bob generates a public/private key pair
Alice feeds Bob's public key into the KEM algorithm to create and encapsulate an AES key
BOB uses his private key to decapsulate the AES key
QC-MDPC (Quasi Cyclic - Moderate Density Parity Check) is (hopefully) a quantum-safe KEM
A hybrid technique increases the security

24. Documentation
Specification of extensions with procedures, e.g., for public-key certificates, is in Rec. ITU-T X.509 | ISO/IEC to be finally approved later this year for publication early 2020
Migration techniques for communications protocols provided as normative ASN.1 specifications and as an informative annex within Rec. ITU-T X.510 | ISO/IEC Final approval expected spring 2020 and publication later 2020.
The protocol specified by Rec. ITU-T X.510 | ISO/IEC includes the migration methods (taking its own medicine)

25. End