1 / 13

November 25, 2004. Brussels

Workshop on algorithms and parameters for Electronic Signatures draft ETSI TS 102 176-2 V.0.1.0 (2004-11). November 25, 2004. Brussels. Part 2: Symmetric algorithms and protocols for secure channels. Secure messaging for smart cards 5.1 General 5.2 Channel keys establishment

lindaking
Download Presentation

November 25, 2004. Brussels

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Workshop on algorithms and parameters for Electronic Signaturesdraft ETSI TS 102 176-2 V.0.1.0 (2004-11) November 25, 2004. Brussels

  2. Part 2: Symmetric algorithms and protocols for secure channels • Secure messaging for smart cards • 5.1 General • 5.2 Channel keys establishment • 5.2.1 Authentication steps • 5.2.2 Session Key creation • 5.2.3 Compute channel key • 5.2.4. Compute send sequence counter SSC • 5.3 Secure Messaging Mode • 5.3.1. CLA byte • 5.3.2. TLV coding of command and response message • 5.3.3. Treatment of SM-Errors • 5.3.4. Padding for checksum calculation

  3. Context • Host Application (HA): An application able to establish a secure channel with the SCDev. • InterFace Device (IFD): A device that is the physical interface by which the communication between the card and the host application is handled. The communication may be with a contact interface, a contactless interface, or both.

  4. Secure Channel • Based on symmetric channel keys. • one for the computation of a Message Authentication Code (MAC) • another one to be used for confidentiality when needed. • These channel keys may be: • preinstalled  “Static Secure Messaging” • dynamically negotiated  symmetric channel keys must be established using symmetrical or asymmetric cryptography.

  5. Channel Keys Establishment • Symmetrical method : channel keys are derived after the establishment of a single Session Key KSK. • Once the channel keys are established, a trusted channel is then available to protect or conceal the information transmitted over the interface from either side. • Asymmetric methods not considered for the moment  future evolutions

  6. Secure Messaging Mode • Consistent with ESIGN-K (CEN/ISSS) • CWA 14 890-1: “Application interface for smart cards used as secure signature creation devices - Part 1: basic requirements” • Use of TDES for: • Integrity: Cryptographic Cheksum = ANSI Retail MAC using TDES • Confidentiality: CBC TDES Encryption/Decryption • AES to be considered for future evolution

  7. Confidentiality

  8. Integrity

  9. Smart Cards

  10. Part 2: Symmetric algorithms and protocols for secure channels • Secure messaging for smart cards • 5.1 General • 5.2 Channel keys establishment • 5.2.1 Authentication steps • 5.2.2 Session Key creation • 5.2.3 Compute channel key • 5.2.4. Compute send sequence counter SSC • 5.3 Secure Messaging Mode • 5.3.1. CLA byte • 5.3.2. TLV coding of command and response message • 5.3.3. Treatment of SM-Errors • 5.3.4. Padding for checksum calculation

  11. Comments from ECRYPT (1) • Sect 5.2.1: “KMAC and KENC shall be different and…”, different is rather weak, maybe write “cryptographically independent”. • Answer: modify sentence as suggested: • “KMAC and KENC shall be cryptographically independent and shall be both available on the HA and the SCDev side.”

  12. Comments from ECRYPT (2) • Sect 5.3.5.1: “security implications as described in [5]”. The example given in [5] is rather contrived (though valid from soundness point of view). However, a probably more important aspect is to verify the integrity before consuming resources to decrypt, i.e. a probably equally important aspect is to limit denial-of-service. • “A cryptogram (Tag = ‘87’x) is always followed by a cryptographic checksum with Tag = ‘8E’x. Encryption must be done first on the data, followed by the computation of the cryptographic checksum on the encrypted data. This order is in accordance with ISO/IEC 7816-4 [2] and has security implications as described in [5].” • [5] “The order of encryption and authentication for protecting communications (or: How secure is SSL?)” by Hugo Krawczyk. • Answer: Add a paragraph explaining that the receiver shall verify integrity before decrypting (in the case of secure messaging with both integrity and confidentiality).

  13. Comments from ECRYPT (3) • Sect 5.3.5.2: it is known that this MAC (the “ANSI retail MAC”) breaks down after 232 MACs. This seems not to be a problem here, but could be noted. • Answer: Add a note in 5.3.5.2, with reference to • B. Preneel and P.C. van Oorschot, “A key recovery attack on the ANSI X9.19 retail MAC”, Electron. Lett., vol. 32, no. 17, pp. 1568-1569, 1996.

More Related