1、American National StandardDeveloped byfor Information Technology Generic Identity Command Part 3: GICS Platform Testing RequirementsINCITS 504-3-2016INCITS 504-3-2016INCITS 504-3-2016American National Standardfor Information Technology Generic Identity Command Set Part 3: GICS PlatformTesting Requir
2、ementsSecretariatInformation Technology Industry CouncilApproved October 12, 2016American National Standards Institute, Inc.Approval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards
3、 developer.Consensus is established when, in the judgement of the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that al
4、lviews and objections be considered, and that a concerted effort be madetowards their resolution.The use of American National Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchas
5、ing, or usingproducts, processes, or procedures not conforming to the standards.The American National Standards Institute does not develop standards andwill in no circumstances give an interpretation of any American NationalStandard. Moreover, no person shall have the right or authority to issue ani
6、nterpretation of an American National Standard in the name of the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised or
7、withdrawn at any time. The procedures of the American National StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNatio
8、nal Standards Institute.American National StandardPublished byAmerican National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2016 by Information Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electroni
9、c retrieval system or otherwise,without prior written permission of ITI, 1101 K Street NW, Suite 610, Washington, DC 20005. Printed in the United States of AmericaCAUTION: The developers of this standard have requested that holders of patents that may berequired for the implementation of the standar
10、d disclose such patents to the publisher. However,neither the developers nor the publisher have undertaken a patent search in order to identifywhich, if any, patents may apply to this standard. As of the date of publication of this standardand following calls for the identification of patents that m
11、ay be required for the implementation ofthe standard, no such claims have been made. No further patent search is conducted by the de-veloper or publisher in respect to any standard it processes. No representation is made or impliedthat licenses are not required to avoid infringement in the use of th
12、is standard.i Table of Contents Foreword iii 1. Overview 1 1.1 Purpose and Scope 1 1.2 Normative References 2 2. Definitions, abbreviations and conventions . 4 2.1 Terms and Definitions . 4 2.2 Acronyms, Abbreviations and Symbols 5 3. Requirement Definition Method . 9 4. GICS Test Requirements Card
13、Application Command Set . 9 4.1 Test of Data Structures for GICS-Applications . 9 4.1.1 Global Objects 9 4.1.2 Files 11 4.1.3 Data Objects . 13 4.2 Security Architecture. 15 4.3 Assigned Values . 17 4.4 Generic Identity Command Set Application . 23 4.4.1 SELECT 23 4.4.2 SELECT DATA . 26 4.4.3 GET DA
14、TA 26 4.4.4 PUT DATA 29 4.4.5 VERIFY . 31 4.4.6 CHANGE REFERENCE DATA 33 4.4.7 RESET RETRY COUNTER 34 4.4.8 MANAGE SECURITY ENVIRONMENT (Set) 35 4.4.9 GENERAL AUTHENTICATE 36 4.4.10 PERFORM SECURITY OPERATION 37 4.4.11 GET RESPONSE (For Transmission Handling) . 39 4.5 Operation 39 4.5.1 Model of Com
15、putation . 39 4.5.2 Interindustry Data Objects 39 4.6 Signature and Key Establishment Protocols 40 4.6.2 Signature Protocols 40 4.6.3 Key Establishment Protocols 41 4.6.4 Session Key Establishment 41 4.7 Secure Messaging 42 4.7.2 AES Secure Messaging 42 4.8 Card Manager Application (INCITS 504 Part
16、2 Test Requirements) . 43 4.8.1 Overview . 43 4.8.2 Initial-GICS State 44 4.8.3 Updates. 45 4.8.4 Commands . 46 4.8.5 Data Structure . 46 4.8.6 Card Identification Scheme 48 4.8.7 Card Management Scheme 48 4.9 Application Management 49 4.9.1 Application Life Cycle . 49 4.9.2 Security Attributes . 49
17、 4.10 File Management 49 4.10.1 File Life Cycle . 49 4.10.2 Data Structures for File Management . 49 4.11 Key Management 50 4.11.1 Key Life Cycle . 50 ii 4.12 Authentication Objects Management 50 4.12.1 Authentication Objects Life Cycle . 50 4.13 Administrative Command Set . 50 4.13.1 APPLICATION MA
18、NAGEMENT REQUEST. 50 4.13.2 REMOVE APPLICATION . 51 4.13.3 CREATE DO . 51 4.13.4 DELETE DO . 52 4.13.5 CREATE FILE . 52 4.13.6 DELETE FILE . 53 4.13.7 ACTIVATE FILE 53 4.13.8 DEACTIVATE FILE . 53 4.13.9 GENERATE ASYMMETRIC KEY PAIR . 54 4.13.10 PUT DATA (Key) 54 iiiForeword (This foreword is not par
19、t of American National Standard INCITS 504-3-2016.)This American National Standard describes the test requirements for the GenericIdentity Command Set.Requests for interpretation, suggestions for improvement or addenda, or defect re-ports are welcome. They should be sent to the International Committ
20、ee for Informa-tion Technology Standards, 1101 K Street, NW, Suite 610, Washington, DC 20005.This standard was processed and approved for submittal to ANSI by INCITS. Com-mittee approval of this standard does not necessarily imply that all committee mem-bers voted for its approval. At the time it ap
21、proved this standard, INCITS had thefollowing members:Philip Wennblom, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems, Inc Scott FosheeSteve Zilles (Alt.)AIM Global, Inc. Steve HallidayMary Lou Bosco (Alt.)Chuck Evanhoe (Alt.)Dan Kimball (Alt.)Apple Helen
22、e WorkmanMarc Braner (Alt.)Virginia Fournier (Alt.)David Singer (Alt.)Dell, Inc. David BlackSaid Tabet (Alt.)Department of Commerce - NIST. Michael HoganWo Chang (Alt.)Sal Francomacaro (Alt.)Elaine Newton (Alt.)Distributed Management Task Force (DMTF) John CrandallHemal Shah (Alt.)Farance, Inc Frank
23、 Farance Timothy Schoechle (Alt.)Futurewei Technologies, Inc. Yi ZhaoWilbert Adams (Alt.)Timothy Jeffries (Alt.)GS1GO. Charles BissAndrew Hearn (Alt.)Edward Merrill (Alt.)Hewlett-Packard Enterprise Joel Fleck IIHP, Inc Karen Higginbottom Paul Jeran (Alt.)Beatrice Tam (Alt.)IBM Corporation Steve Holb
24、rookAlexander Tarpinian (Alt.)IEEE . Jodie HaaszVictoria Kuperman-Super (Alt.)Don Wright (Alt.)Intel Corporation . Philip Wennblom Stephen Balogh (Alt.)Grace Wei (Alt.)Microsoft Corporation . Laura Lindsay John Calhoon (Alt.)ivOrganization Represented Name of RepresentativeOracle Corporation . Donal
25、d R. Deutsch Patrick Curran (Alt.)Anish Karmarkar (Alt.)Michael Kavanaugh (Alt.)Peter Lord (Alt.)Jim Melton (Alt.)Jan-Eike Michels (Alt.)Toshihiro Suzuki (Alt.)Purdue University Stephen Elliott Kevin OConnor (Alt.)Telecommunications Industry Association (TIA) Florence OtienoStephanie Montgomery (Alt
26、.)US Department of Homeland Security . Peter Shebell Juan Gonzalez (Alt.)Teresa Lustig (Alt.)Gregg Piermarini (Alt.)Technical Committee B10 on Identification Cards and Related Devices, which re-viewed this standard, had the following members:Brian Beech, ChairGene Meier, International Representative
27、Organization Represented Name of RepresentativeAAMVA. Geoff SlagleLoffie Jordaan (Alt.)ABnote North America Donald DupuisCET Films, a division of Nekoosa Holdings, Inc. Shannon Crawford-TaylorCFC International . Dan Szumski Roger Strasemeier (Alt.)Covestro . Frank MannarinoChris Cooper (Alt.)CPI Car
28、d Group Jim ColleranBarry Mosteller (Alt.)Cubic Transportation Systems, Inc. Thomas Busch-SorensenKevin Van Howe (Alt.)Discover Card. Catherine MadisonCheryl Mish (Alt.)Fawad Nisar (Alt.)Lakshmi Ramanathan (Alt.)Michelle Zhang (Alt.)DuPont Teijin Films USLP Ross WattersAlison Kimmitz (Alt.)Jan LaRiv
29、iere (Alt.)Eclipse Laboratories. Brad PaulsonKevin Tall (Alt.)Entrust Datacard. Brian BeechRyan Boudreau (Alt.)Gene Meire (Alt.)Dennis Warwick (Alt.)Exponent, Inc Brad McGoranEllick Chan (Alt.)John Fessler (Alt.)Christian Page (Alt.)Fall Hill Associates LLC Barry KefauverFiTeq Robert SingletonMichae
30、l Scruggs (Alt.)Gemalto Michel Escalant Drew Anders (Alt.)Laurence Bringer (Alt.)Mourad Faher (Alt.)Joel Goldman (Alt.)Yannick Pin (Alt.)vOrganization Represented Name of RepresentativeGiesecke in this standard, it is the GICS Card-Application data elements that are associated with an individual whi
31、ch authoritatively binds an identity (and, optionally, additional attributes) to that individual. Integrated Circuit Card: Electronic component designed to perform processing and/or memory functions. Platform: Specification of a computer systems hardware and operating system software that defines th
32、e environment in which other software operates. Reference Data Qualifier: The reference data qualifier is a reference to a security object such as key or a PIN that is targeted by the APDU command. Secure Messaging: Set of means for cryptographic protection of (parts of) command-response pairs ISO/I
33、EC 7816-4. Security Attribute: Condition of use of objects in the card including stored data and data processing functions, expressed as a data element containing one or more access rules ISO/IEC 7816-4. Security Condition: Boolean expression in security states. Security Environment: Set of componen
34、ts required by a card-application in the card for secure messaging or for security operations ISO/IEC 7816-4. Security State: Boolean variable indicating whether (TRUE) or not (FALSE) a particular security procedure such as an authentication protocol has been successfully executed since the last tim
35、e this variable was set to FALSE. Security Status: Collection of security states. Template: Set of BER-TLV data objects forming the value field of a constructed BER-TLV data object ISO/IEC 7816-4. 2.2 Acronyms, Abbreviations and Symbols For the purposes of this document, the following acronyms, abbr
36、eviations and symbols shall apply. ACD: Application Capability Description ADF: Application Dedicated File AES: Advanced Encryption Standard AID: Application ID AMB: Access Mode Byte ANSI: American National Standards Institute INCITS 504-3-2016 6 APDU: Application Programming Data Unit ASCII: Americ
37、an Standard Code for Information Interchange ASN.1: Abstract Syntax Notation One AS: ASsertion AT: Authentication Template ATR: Answer-to-reset BER: Basic Encoding Rules CAC: Common Access Card CCD: Card Capability Description CER: Canonical Encoding Rules CHV: Card Holder Verification CLA: CLAss by
38、te, the first byte in a command header CP: Control Parameters CRT: Control Reference Template CT: Confidentiality Template CVC: Card Verifiable Certificate DER: Distinguished Encoding Rules DES: Data Encryption Standard DF: Dedicated File DO: Data Object DST: Digital Signature Template DTR: Derived
39、Test Requirement ECC: Elliptic Curve Cryptography ECCCDH: Elliptic Curve Cryptography Cofactor Diffie-Hellman ECDSA: Elliptic Curve Digital Signature Algorithm EF: Elementary File ENC: Encryption FDB: File Descriptor Byte INCITS 504-3-2016 7 FID: File IDentifier FIPS: Federal Information Processing
40、Standard FMD: File Management Data FS: Forward Secrecy GICS: Generic Identity Command Set GUID: Global Unique Identifier HT: Hash Template ICC: Integrated Circuit Card (with or without contacts) ID: Identifier IEC: International Electrotechnical Commission INCITS: InterNational Committee for Informa
41、tion Technology Standards INS: INStruction byte, the second byte in a command header ISO: International Organization for Standardization IV: Initial Vector KAT: Key Agreement Template KDF: Key Derivation Function KEK: Key Encryption Key Lc: Length field for coding the number NcLCS: Life cycle status
42、 byte Le: Length field for coding the number Ne M/O: Mandatory/Optional MAC: Message Authentication Code MF: Master File MGF: Mask Generation Function MOC: Match-On-Card MSE: Manage Security Environment Nc: Number of bytes in the command data field Ne: Maximum number of bytes in the response data fi
43、eld INCITS 504-3-2016 8 Nr: Number of bytes in the response data field NIST: National Institute of Standards and Technology OAEP: Optimal asymmetric encryption padding P1: Parameter 1, the third byte in a command header P2: Parameter 2, the fourth byte in a command header PIN: Personal Identificatio
44、n Number PIV: Personal Identity Verification PIV-I: Personal Identity Verification Interoperable PKCS: Public-key cryptography standards PRF: Pseudo-random Function PSO: Perform Security Operation PSS: Probabilistic Signature Scheme RFU: Reserved for Future Use RSA: Rivest Shamir Adleman RSASSA: RSA
45、 Signature Scheme with Appendix SAM: Secure Access Module SCB: Security Condition Byte SCP: Secure Channel Protocol SEID: Security Environment ID SHA: Secure Hashing Algorithm SM: Secure Messaging SP: Special Publication SPT: Security Parameter Template TBD: To Be Determined TE: TEst Requirement TLV
46、: Tag Length Value VE: Required VEndor Information ZKM: Zero Key Management INCITS 504-3-2016 9 3. Requirement Definition Method All the characteristics of a GICS platform which are described in Part 1 or Part 2 and are central to the concept of an interoperable GICS platform are addressed in Part 3
47、 with conformance test requirements. Specifically, each must, only and shall statements in Part 1 and Part 2 are addressed by the inclusion in Part 3 with a corresponding test requirement. There are no requirements provided for testing of a particular application that is loaded onto the platform. Tw
48、o types of test requirements are presented in this document. Explicit Test Requirements are extracted directly from normative assertive statements from Part 1 or Part 2 with minimal phrase alteration. Derived Test Requirements are used when additional clarification or modification to a condition sta
49、tement is needed to leave no question as to the meaning or intent of testing. Derived test requirements are also used to ensure correct and interoperable behavior intended in Parts 1 and 2. Both types of test requirements consist of the following content: Actual condition statements taken/derived from Parts 1 and 2 these include conditions for successful command execution for each command as well as exception behaviors explicitly specified by statements using the words “shall,” “must,” and other normative delimiters in the standard. The condition statements are
