ETSI TS 102 176-2-2005 Electronic Signatures and Infrastructures (ESI) Algorithms and Parameters for Secure Electronic Signatures Part 2 Secure channel protocols and algorithms for_1.pdf

《ETSI TS 102 176-2-2005 Electronic Signatures and Infrastructures (ESI) Algorithms and Parameters for Secure Electronic Signatures Part 2 Secure channel protocols and algorithms for_1.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 102 176-2-2005 Electronic Signatures and Infrastructures (ESI) Algorithms and Parameters for Secure Electronic Signatures Part 2 Secure channel protocols and algorithms for_1.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 102 176-2 V1.2.1 (2005-07)Technical Specification Electronic Signatures and Infrastructures (ESI);Algorithms and Parameters for Secure Electronic Signatures;Part 2: Secure channel protocols andalgorithms for signature creation devicesETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 2 Reference RTS/E

2、SI-000039-2 Keywords e-commerce, electronic signature, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88

3、Important notice Individual copies of the present document can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version i

4、s the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status.

5、Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification

6、No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2005. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the

7、benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 3 Contents

8、Intellectual Property Rights4 Foreword.4 Introduction 4 1 Scope 5 2 References 5 3 Definitions and abbreviations.6 3.1 Definitions6 3.2 Abbreviations .6 4 Maintenance activities6 5 Secure messaging for smart cards 6 5.1 General .6 5.2 Channel keys establishment .7 5.2.1 Authentication steps7 5.2.2 S

9、ession Key creation.8 5.2.3 Computation of channel keys9 5.2.4 Computation of the send sequence counter SSC.10 5.3 Secure Messaging Mode 10 5.3.1 CLA byte 10 5.3.2 TLV coding of command and response message10 5.3.3 Treatment of SM-Errors10 5.3.4 Padding for checksum calculation 11 5.3.5 Message stru

10、cture of Secure Messaging APDUs11 5.3.5.1 Cryptograms11 5.3.5.2 Cryptographic Checksums 13 Annex A (normative): Use of TDES and AES .15 Annex B (informative): Major changes from previous versions17 History 18 ETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 4 Intellectual Property Rights IPRs essential or po

11、tentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essenti

12、al, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No

13、 guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Electro

14、nic Signatures and Infrastructures (ESI). The present document is part 2 of a multi-part deliverable covering the Algorithms and Parameters for Secure Electronic Signatures, as identified below: Part 1: “Hash functions and asymmetric algorithms“; Part 2: “Secure channel protocols and algorithms for

15、signature creation devices“. Introduction The present document provides for security and interoperability for the application of the underlying mathematical algorithms and related parameters for electronic signatures in accordance with the Directive 1999/93/EC 1 of the European Parliament and of the

16、 Council of 13 December 1999 on a Community framework for electronic signatures. The first part of the present document defines a list of cryptographic algorithms together with the requirements on their parameters, as well as the recommended combinations of algorithms in the form of “signature suite

17、s“ to be used with the data structures defined in the documents developed under the EESSI (European Electronic Signature Standardization Initiative). The present document contains several informative annexes which provide useful information on a number of subjects mentioned in the text. The present

18、part of this technical standard (symmetric algorithms and protocols for secure channels) defines a list of symmetric algorithms and protocols to be used with protocols to construct a secure channel between an application and a signature creation device (SCDev) providing either only integrity or both

19、 integrity and confidentiality. Such a secure channel may be used during the operational phase of a signature creation device to remotely download a private key in the signature creation device, remotely extract a public key from the signature creation device when the key pair has been generated by

20、the signature creation device or/and remotely download a public key certificate and associate it with a private key already stored in the signature creation device. With the kind permission of CEN Management Centre, some parts of the present document reproduce text from CEN Workshop Agreement (CWA)

21、(CWA 14890-1 7), a publication which is CEN copyright. Whereas the CWA 14890-1 is restricted to the usage of Triple DES (TDES) only, the present document gives a more general approach for the application of different symmetric algorithms. It recommends the usage of AES, the successor of DES, approve

22、d by NIST. ETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 5 1 Scope The present document defines a set of symmetric algorithms and protocols to be used to construct a secure channel between an application and a signature creation device providing either only integrity or both integrity and confidentiality.

23、 Such a secure channel is required during the operational phase of a signature creation device to remotely download a private key in the signature creation device, remotely extract a public key from the signature creation device when the key pair has been generated by the signature creation device o

24、r/and remotely download a public key certificate and associate it with a private key already stored in the signature creation device. The protocols and algorithms defined in the present document are consistent with the following document: CWA 14890-1 7: “Application Interface for Smart Cards used as

25、 Secure Signature Creation Devices - Part 1: Basic requirements“. The secure channel is always restricted to the both partners of the communication and can be defined even in a proprietary way without loss of interoperability. The present document gives one possibility to set up the secure channel,

26、other methods may be used as well and are not ruled out hereby. Patent related issues are out of the scope of the present document. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either spec

27、ific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected l

28、ocation might be found at http:/docbox.etsi.org/Reference. 1 Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures. 2 ISO/IEC 7816-4 (2005): “Identification cards - Integrated circuit cards - Part 4: Organization, se

29、curity and commands for interchange“. 3 ISO/IEC 9797-1 (1999): “Information technology - Security techniques - Message Authentication Codes (MACs) - Part 1: Mechanisms using a block cipher“. 4 ISO/IEC 11568-2 (1994): “Banking - Key management (retail) - Part 2: Key management techniques for symmetri

30、c ciphers“. 5 “The order of encryption and authentication for protecting communications (or: How secure is SSL?)“ by Hugo Krawczyk. In Advances in Cryptology - CRYPTO 2001, volume 2139 of Lecture Notes in Computer Science, pages 310-331, Springer-Verlag, 2001. 6 ANSI X9.63: “Public Key Cryptography

31、for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography“. 7 CWA 14890-1: “Application Interface for smart cards used as Secure Signature Creation Devices - Part 1: Basic requirements“. 8 FIPS Publication 46-3 (1999): “Data Encryption Standard (DES)“, Na

32、tional Bureau of Standards. 9 FIPS Publication 197 (2001): “Advanced Encryption Standard (AES)“, National Institute of Standards and Technology. ETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 6 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and

33、 definitions apply: host application: application able to establish a secure channel with the SCDev interface device: device that is the physical interface by which the communication between the card and the host application is handled NOTE: The communication may be with a contact interface, a conta

34、ctless interface or both. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AES Advanced Encryption Standard APDU Application Protocol Data Unit CLA CLass byte of an APDU CWA CEN Workshop Agreement DES Data Encryption Standard DO Data Object FCP File Cont

35、rol Parameters HA Host Application IFD InterFace Device MAC Message Authentication Code SAGE Security Algorithms Group of Experts (from ETSI) SCDev Signature-Creation Device SM Secure MessagingTDES Triple DES 4 Maintenance activities As a response to relevant developments in the area of cryptography

36、 and technology, activities for the maintenance of the symmetric algorithms and protocols for secure channels shall enable dynamic updating of the lists of recommended algorithms and protocols. An initial list of recommended symmetric algorithms and protocols for secure channels is given in the pres

37、ent document. The present document describes the establishment of two symmetric channel keys using symmetric cryptography only, and does not consider an option for asymmetric cryptography. However, in the future, there can be evolutions towards asymmetric mechanisms for establishing secure channels

38、keys between HA and SCDev. The maintenance activity is carried by ETSI ESI with the cooperation of the SAGE group. In order to allow an easy follow up of the present document, a history of the changes will be maintained. 5 Secure messaging for smart cards 5.1 General The secure channel, while being

39、used, is based on symmetric channel keys. There are two channel keys: one for the computation of a Message Authentication Code (MAC) and another one to be used for confidentiality when needed. These channel keys may be preinstalled or dynamically negotiated. ETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 7

40、 The former case is called “Static SM“ where static symmetric channel keys are reserved for secure messaging. In that case the channel keys are always available in the card. A key agreement/derivation method is therefore not required. In the later case, symmetric channel keys must be established usi

41、ng symmetrical or asymmetric cryptography. The present document does not consider, for the moment, asymmetrical cryptography to establish the negotiated channel keys. However, in the future, there can be evolutions towards asymmetric mechanisms for establishing secure channel keys between HA and SCD

42、ev. When symmetrical cryptography is used to establish the channel keys, these 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 ei

43、ther side. 5.2 Channel keys establishment According to ISO/IEC 7816-4 2 a cryptographic mechanism for confidentiality consists of an algorithm in a mode of operation. In the absence of explicit indication and when no mechanism is implicitly selected for confidentiality, a default mechanism shall app

44、ly. When symmetrical cryptography is used, a single Session Key is established after a successful mutual authentication. The key used for confidentiality KENCand MAC computation KMACare derived from the Session Key. They shall be available on HA and SCDev side. The keys KENCand KMACused in authentic

45、ation protocol are replaced as soon as a fresh session key is negotiated by HA and SCDev. For the HA, the TDES algorithm SHALL be supported while the AES algorithm SHOULD be supported. For the SCDev, either the TDES algorithm or the AES algorithm SHALL be supported. NOTE: The AES algorithm is an alt

46、ernative for future use which currently may not be supported by SCDevs. The current protocol was designed to support a single algorithm (TDES) and does not allow to negotiate the algorithm: the host has to know in advance the single algorithm supported by the SCDev or it extracts this information fr

47、om elsewhere, for example from the file control parameters (FCP file descriptor extension tag “85“) of the file containing the key according to ISO/IEC 7816-4 2. The mode of operation SHALL be CBC i.e. cipher-block-chaining. 5.2.1 Authentication steps The authentication scheme follows the protocol d

48、escribed in CWA 14890-1 7, section 8.7.1. We use in the following the notation EKENC(data) to describe the encryption of “data“ using key KENC. The notation MACKMAC(data) describes the computation of a MAC over “data“ using key KMAC. ETSI ETSI TS 102 176-2 V1.2.1 (2005-07) 8 Step IFD Transmission SC

49、Dev 1 READ BINARY of file EF.SN.SCDev or GET DATA respectively barb2right barb2left Read data from specified file SN.SCDev as response 2 GET CHALLENGE barb2right barb2left RND.SCDev 3 MUTUAL AUTHENTICATE Generate Key KHAS = RND.HA | SN.HA | RND.SCDev | SN.SCDev | KHAEKENC(S) | MACKMAC( EKENC(S) barb2right SCDev decrypts input and compares RND.SCDev with the previous response. Verify RND.SCDev, SN.SCDev Generate Key KSCDevGenerate Session Key KSK(see 5.2.2) Generate SSC.SCDev 3 Verify RND.HA, SN.HA Generate Session Key KSK(se