ANSI ASC X9 X9.24-1-2017

American National Standard for Financial Services ANSI X9.24-1-2017 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques Ke» Accredited Standards Committee ¥ 9 Inc. Financial Industry Standards Accredited Standards Committee X9, Incorporated Financial Industry Standards Date Approved: June 8, 2017 American National Standards Institute American National Standards, Technical Reports and Guides developed through the Accredited Standards Committee X9, Inc., are copyrighted. Copying these documents for personal or commercial use outside X9 membership agreements is prohibited without express written permission of the Accredited Standards Committee X9, Inc. For additional information please contact ASC X9, Inc., 275 West Street, Suite 107, Annapolis, MD 21401. This page left intentionally blank ANSI X9.24-1-2017 Contents FIQUIFOS ........cescessssesceecesesecseesseassaeseneneenseessassesassasenseesessnssessassessessassessnsseessssessessesaeseeseeeaeeessaesaesassassaneeseaseeesaseaseaseaeeases iii Table ......ccscssscsssseeseeesseesseesessaessesseesseeseeessessessaeeeeesensseesseesaessessesseeesaasceeeseasessausseeseeeseessesssusseesaesseeseeeseesenessessasenessansens iv FOPQWOT .....eccecsessscesseseeeecseenssessaeeeecessnsseesassassessesenseeseessnseessessessesaeseesenseessessesaesaesesseeseeseesessaesassessenseeeessessessessassassessenees Vv INtPOCUCTION .......... ee eeeeseeseeeeececesseeseeeseeseceaeesaeesessaaesaeeaeesaeeaeseaeesessaaeaeeaeeeaceaassaesaaseaaesaseaeeeaessaseaeeneseaseaesaaseeesassaaesnenees vi 1 PULPOSG ......eecessessesnseseesseeaeeceeesneeseesaesaeeseceseesaeesaeesessasesessaceceesaessaeesesenssseesaneseesaeesaesaessassaasseessesenseassanssensseeees 12 2 SCONE ooo. eeececseseesecseecsaeeseeseceseessesseeesessaaeseseaeeseesaeseeecsessaeeseseseeseecseseesesaseaesaeeaeeseeesessaeseassaessaceeeseeseasesessaeeseseags 12 2.1 GeMe ral .......eeseeseesesessseeeseceecensensseesessessecseseesseseesasseesaesaesassensaeseeseeseesassassassesseesesseesessassassasenseessessessessesseseeseesees 12 2.2 Application ...........cccccscecssessseesseesseesseessecessecssneeseeseseeesueseseesseessnsesseecseesenseesaeesueesuessauseseeeseeeesaeecsneesensesnseenees 12 3 REfEreNCES .......cceccsccsscssssecsccsecaessecsessesaecaecaesaesassaesassassessaesassanseesessassessesseseaesessessesensesseeeeeeeesesenseessnseneeesaneees 13 4 Terms and Definitions ......... ee ccceccsceseseeseeseeseeeeseeaseaeesenseeeeeeceaeeassaesansaeeaseeseaesaseassaseesseseeseeseensaseeseenseneeeas 14 5 Standard Organization ...........ceccsccsccssseeeseeeseeseesecsesessseseeseeeeeeeseassessassenseeeesseseessessasseseeseseeseeseeseeseeseeseesenees 21 6 Payment Environment..........:ccscccscssssssesseseesseeseessesseessesseesseeseeeseessessaeseeaseesseeseeessessesseseeesseesseeseeeseessnssaesenses 22 6.1 6.2 6.3 GeMe ral ........eceeeessssesssssesecseceeeseeseeseeeesecseseeeseeseeaseaessecaesassaneaesaesensaesassassasaseaeseseeesassassassaseeseesseseessassasseseneeatees 22 Cardholder and Card ISSUGP ..........:csccsscesesseesseseeesseceecaeeenecesecseceecaseaseacenseeeseeseesassassasaseneeesseseessassaseaseneatess 22 Card ACCeptol .........cccccsccsccssesceseeseesecsecsesseeseceeaeeaecaesaecaesaeeaesaeeaecaecaesassaseaseaesaeeaesaesassassaseeeseseeseesaesseseeseesatens 22 6.4 ACQUIIEL .......2.c2ccceccesccesssscssscesecsnseseesseeseeseeesnesaecsusnsesseeeseesueesnssaessssesesseecaesessesessaesanscaesassseseseesnssaessaseesenseanseaes 22 6.5 SWItCH ooo. eeeeeeeesecsecsecseeseeseesessessecsecseeseeseesesaeeseesecaeeaesaesaecaceaeeaseassassassassaeeeeeaesessassassasseseseeseeesaseassensessesenees 22 7 7.1 7.1.1 Key Management Requirement .............:ccscssssessssssssesseseeeseeseesaeeaseassaceseeeseeseesassassasseseeesessesseseeseatsesenseeees 23 GeMe ral ........ecesseesesesssssesecsecensensseeseesessecsesensensaneaseaessecaesaesaneeesaeeeeseecassassaseaseaseasseesassassassasenseeseesessassassesensasens 23 Dual Control and Split KnowWledge............:eccessecceecsscssseeeeeeeeeeceesseeaseasenseeesesseesassessasesenseesseseesenssassesensesens 23 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.1.7 Permissible Key Forims...............c:ccsccsscssscssssssessessessessesseecseesaeeseessesseessaesaessnssaeseeeseesseessaeeaesseesanseaesonseanssnseas LOQGING.........:ccscescessscsecsesseessesseessesseecaeesaeesessacessessesseessessaesseesaeesaesseseesssuesuessussaessessseseaesaaesaessessanseassoeseanssaseas Key Strength ..... ce cccscscssesseseesseesessessesseseessesseseeseessesesenseeseseeseesaesessesseeseesesseusessessegseaseseeseessessesessesseseesenees Key LOCAtIONS 0... sesecsesseseeseeseeeseesesseseesenseessesenseeseseesausnceesedsenseesessesseeseseesseuseusessedsessesensseusesseseessessesenssasees Production Key USage ........:ccsescsscsesesseseeeseessesseeesesseesseeseessaesseseesssesseeseesseesseeenessesssensensseesenseasseesseessenees Single Purpose Key USC ..........cecceccecceceseeeeeeeeceeeeeecseeaeesnesnesecaecaesaeeaseassaseassansensaeeassasseseaseeseeneeseaseaseneeeesateas 7.2 Secure Cryptographic Device (SCD) ............sceccesscesseeeeseeeeseeeeeeseeeesesaesenaesenaeseeseeasseaesesaneenaenenaetaneeneneenaees 25 7.3 7.3.1 7.3.2 7.3.3 7.4 7.4.1 7.4.2 Environments ..........:cccccccecceeseeseeseesecseceseeesecsecaeeaecsecaecaesaeeaecaeeaecaecaeeassaseaseaesaesaesaesassassaseeeeesseseeseeeesseeeeeaeens Minimally Controlled Environment ...........cccccscssssesssseeseesseesseesessnseseeseeeseeseeesnessessasssenseeeseeseesasssassenssesees Controlled EnvironMent...........cccsscsssecssssssessessessseesesseeeseeseeesseesessessseeseeseeseeesneesessassseeeeesseseenseasssnssenssaseas Secure ENVirOnMent.........ceccecessessecsesssseeesseesseesesseessesseneseeseeesaeesessasserseeeeeseeeesaeeessasssesseeeseseaessaesenseaeseeeegs Key BIOCKS .......ccccsssesccssecsesseeseessecseeseeseesessaeesaessessaeesessaeesessaecaaesseseasesessaeseeesaeseaseseseaesaesaeseeseaeseaesonseaeesaseas Overview of key DIOCKS..........ccccccscssessesesseesessesseessesseeseesaeesaessessaessaesaeseaesaeseeeeessaesaaeeaesseseaaseaesoeseaessaeeas Key attributes occ ccceseseeseeseeseeeecseseeeeeseeseesecsecsecaesaessesaenaesaecaeeassaseaseassaesensaeeaseassaseeesesseneeseessasseseeseateas 26 26 26 26 26 26 27 7.4.3 7.4.4 7.5 7.5.1 Integrity of the key DIOCK «0.0.0... cccsscscsssesseseseesseeecsececsesseesceseseeseecassassacaseeeseeseesaseaseassesenseeesessessassansasensatees Key and Sensitive Attributes Field oo... eeecssssssssessesesesecseceeeeseecseceeeseeseesaseassassesenseeeseseeseessassesensseeees Key Creation..........ccccccccsscssscssessecsessessessecsecaesacseesaesessaesaeeassaeseesassassassasseseassessessaseessasseseeeseseeseeseessesseseeseatees Random Key Genreration............ccccccccsccssessessescesecsecsecseeseeseesecaecaecaecaeeaseaseaeeaesaesaseassassaeeaeeaseeseeseassasseeeesasens 27 28 28 28 7.5.2 7.5.3 Key Derivation............:cccccsssssssssssessecsssssessessseessessesseessessaussessaeeseesesseesseesaessuesaessesssessaessassessessaneseeseeseanssaseas 28 Key Calculation (Variants) ............c:cccsscsssssssesssssessessseeseessecseessessesssaesaesseesaesseessessaesaaeseesessaessassoesennssaseas 29 7.6 7.7 7.7.1 7.7.2 7.8 7.8.1 23 24 24 24 24 24 Key Component and Key Share Creation ........cccscscsesesessessessessssessessessessessessessessessessessessessessessessessenens 29 ChecK Value ......ccsescscssessseeeeseeecseseeeeseeseseneseesseesesseesaessensseeseeeseesaessaeeeesseeeseesaeesaesnesseseensseneseesensseessessaetenees INGPOCUCTION . 0... eee eccccteeeeeeseneeeeseeseesaeesaeeeeesaeesaesaeesaeesessaesseeeaeeaaeeseseeesaeesaeseeesaeeeaeesessaesaaesaeseeseaeseaeseeseaessaeeas Check Value Calculation..........ccccccsccsssssssscsesecsecsecsessecsessesaecaesaecassasseesaesaeseesaesassasseseaesasseseessassasenseessntons Key Distribution «0.0.0.2... ceeeeecceceeececeseeeeeeeseesaeeseeeaeeseesaeeseeeaeesaeeseseasesaesaeeseseaeeeaeeseseaesaaesaeeeeseaeeeaeseeseeeesaeeas INtrOAUCTION 00.0... eececceceeceeeseeeeeeeesetsecseseeeeeaeeaeeaecaecaecaesaeeaesaceaecaecaseassassaseaesaesassaseassasseseeseaseeseeesassateeseesaeens © 2017 ASC X9, Inc. — All rights reserved 29 29 30 30 30 i ANSI X9.24-1-2017 7.8.2 7.8.3 Personal Conveyance of Cleartext Components or Shares..............:ccsceseeeeeceeeeeeeeeeeeeeseeeeeneeeseneeneeneeseats 30 Transporting Cleartext Components or Shares ..........csccsssssssesceeseeessessesessasseceeeeeeseesaesaseessesseesessesseseesents 30 7.8.4 7.9 Transporting Cleartext Keys Using a Portable Key Loading DeViCE...............::cscseesesseeesseeeeesenseneeeeees 31 Key LOading ........ceccecseeeseseesesseeseseeseeseeseeseesesseseesensaeeesenessesaesaasaceeseeseesseesassassaseeseassessessassaseaseesessesseseeseesents 33 7.9.1 7.9.2 7.9.3 7.10 7.11 G@Me@r Al... ee eseescssececssseesceseeesneesecsesceeeseeeeeseessaseseecanseaesaeeeessessassaeeeasseeseaeseaesaassaeeaeseaeeseesaessaessassassaneesessaeeaeseaes Loading Key Components or Shares......ccccsssssscessessseessessssesseeeeseeseesseesessessesseseeeseeseesesseaseasessessessensensensens Cleartext Key LOading.......ccccsssssssesssseeseesssseesseseeseseeseeseseuseeseeseeseesseseaseasessesseeseuseusedseaseaseseessessensensetonts Key UtiliZation ....... ccc ccccsecsecsecseesseeseecsesseseseseaecseesseeseeesesseesaeseaeseeseaesnscaassaeeseseaessaeeaeseaessessaeeseeneeseaesonseaes Cleartext Key Component and Share Storage .........csscsssssssceseeeseeceeseeserssseseeeseeseesensnsesseseesseesensensenents 7.12 7.13 7.13.1 Key Replacement ............esccsscsseseessseeseeseeseesesseesesseeseeseceeesessesansaceeseeeseeseesassansassaseeesesseesassassessassessersesseseeseats 36 Key De@Struction oo... eeescsessesseesseeeseeseeseesessessessneeseeeseessessesassacsaseesseeseesassassasseseeesesseesassassasseseessessesseseeteats 37 Gemeral ......cceccsccsssessessessseesessecseeseeesensseeesenssaeeseseesensaceaeeeessesaesaaseceeseesenesaesassaseaseeseessessessassaseaseeseessesseseesensents 37 7.13.2 7.13.3 7.13.4 7.14 — 7.15 —§ Key Destruction from an SCD oe eecscssssssseeeesseeeseeseeeseessesaneceeseeessceseessassaeeseeeseeseesaessaessateaesaesesessaeeseseaes Destruction of a Key in Cryptogram Form ..........:ccsscssccssssscssssssesesssessessessaesseseensseesaesssessusseessnsesessaeeanesaes Component and Share Destruction .........cccscccecsssessesessessecsesenseeseeeesesssessaeseeeseeseesaeseaeesessasssnsseesseesenseaes Key Archiving ......ecscscsssssseseeseessesseseeseeseeseessesseseeseeseeseeseeseesesseceesseeseeseesedseaseaseseeeseuseusedseaseaseseesseusensensensens Key Compromise .......cccccscsecsessessesssessecerseeseesesseseeceeceeseeseseeseasecseseeeseeseeseasessessesseeseuseusedseasesseseesseusensenseneets 33 33 34 35 36 37 37 37 37 38 8 Symmetric Key Management Specifications ............eecssssessccseseeeeeeseeseessesseeesesseesesssessaessesseeesesseeeeneees 39 8.1 GeMe ral 0... .eceeesescescescesceseeseeseeaeeseeseeaeeaeeaesaesaesaesassaeeaesaesaesaesassassaesaeeaesaseaesassassassaesaeseseseaseassaseeseseeneeseetasaas 39 8.2 Method: Fixed KeYS ........c:ccscccsscsssssecsessesssecsecseeesesseesessaesseessesseeesessaesaescaesseesseseeseeesaesaesesessessaeesesesessaeeaseaes 39 8.3 Method: Master Keys / Session KeYS ......:cssscssssssessesessesessesesseeeeeessesessesesesaseseesesseseesesaesesasesseneeseseesenaess 39 Annex A (Normative) Key and Component Check Values..........c:cscsscsssscsscssssessesessessessesaeseessssassassassessessessessatons 40 Annex B (Normative) Split Knowledge During Transpott............:cssscsssesseeseessssesessesseeseeseeseesasseseaseeseessenseseesentans 43 ii © 2017 ASC X39, Inc. - All rights reserved ANSI X9.24-1-2017 Figures Figure 1 — Example of XOR Function to Combine Key Component ............c ccc ceesssesseesseneeeesseseeeesessseeensesenenaes 26 Figure 2 — Key Block Overview Example.........cccceeesceceeseseeeessesensesescesecscsssesecesessesesesseseseesscsesesssseenasassenenaes 27 Figure 3 — Legacy Generation of Key Check Value... cece eeeeneneeeeneeecesnescecsseneesssseeessssereesasssieassesssenenaes 40 Figure 4 — CMAC Generation of Key Check Value..........:ecececeeeecceeeseeeesseseseesssesecesacsesaesessesecsesaesesaseesseeeseseaseaeasens 41 © 2017 ASC X39, Inc. — Alll rights reserved iii ANSI X9.24-1-2017 Tables Table 1 - Complete Hex Values for R, © 2017 ASC X9, Inc. — All rights reserved ANSI X9.24-1-2017 Foreword Approval of an American National Standard requires verification by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made toward their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretation should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken to reaffirm, revise, or withdraw this standard no later than five years from the date of approval. Published by Accredited Standards Committee X9, Incorporated Financial Industry Standards 275 West Street, Suite 107 Annapolis, MD 21401 USA X9 Online http://www.x9.org Copyright © 2017 Accredited Standards Committee X9, Inc. All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America. © 2017 ASC X9, Inc. — All rights reserved Vv ANSI X9.24-1-2017 Introduction The user's attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of this claim or of any patent rights in connection therewith. The patent holder has, however, filed a statement of willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the standards developer. Today, billions of dollars in funds are transferred electronically by various communication methods. Transactions are often entered remotely, off-premise from financial institutions, by retailers or by customers directly. Such transactions are transmitted over potentially non-secure media. The vast range in value, size, and the volume of such transactions expose institutions to severe risks, which may be uninsurable. To protect these financial messages and other sensitive information, many institutions are making increased use of the American National Standards Institute Triple Data Encryption Algorithm (TDEA) and the Advanced Encryption Standard (AES). Specific examples of its use include standards for message authentication, personal identification number encryption, other data encryption, and key encryption. AES and the TDEA are in the public domain. The security and reliability of any process based on AES or the TDEA is directly dependent on the protection afforded to secrets called cryptographic keys. This part of this standard deals exclusively with management of symmetric keys using symmetric techniques. ANS X9.24-2 addresses management of symmetric keys using asymmetric techniques. A familiar analogy may be found in the combination lock of a vault. The lock design is public knowledge. Security is provided by keeping a number, the combination, a secret. Secure operation also depends on protective procedures and features which prevent surreptitious viewing or determination of the combination by listening to its operation. Procedures are also required to ensure that the combination is random and cannot be modified by an unauthorized individual without detection. Suggestions for the improvement or revision of this Standard are welcome. They should be sent to the X9 Committee Secretariat, Accredited Standards Committee X9, Inc., Financial Industry Standards, 275 West Street, Suite 107, Annapolis, MD 21401 USA. This Standard was processed and approved for submittal to ANSI by the Accredited Standards Committee on Financial Services, X9. Committee approval of the Standard does not necessarily imply that all the committee members voted for its approval. At the time this standard was approved, the X9 committee had the following members: Roy DeCicco, X9 Chairman Angela Hendershott, X9 Vice-Chairman Steve Stevens, Executive Director Organization Represented Representative ACI WorldWide uu... cccccccccsccscccsssssecsscssecsecsesseecsssseecseseeecseseeessesseseassseseaesaeesaeeaees American Bankers ASSOCI&tION ........0..:cccecceteeseeseeeeseeeeeeceesecsecaeceeceecesaesesesaesaeeetens American Express COMmpany .......cccccccccscssssscssessecssessesseesessesssesseserscsesereseseesesresas Bank Of AMELICA ....... cee eececcescceeeeneecseeeecseceeccaeecsesesesessescaeceeeesecesesestaeeneseaeeneeeaeensees Dan Kinney Diane Poole David Moore Daniel Welch Blackhawk Network .......c:cccccccescssesecsessecseeseeseeessesseceseeseeeeeseeseeseesesssessesseseeseesaeeneens Anthony Redondo vi © 2017 ASC X9, Inc. — All rights reserved ANSI X9.24-1-2017 Bloomberg LP uuu... ceeeceseseeseeeeeseeeecsecsecaeeeeeeecaecaeceecaeeaeeeseeseescaeseeceseeseeseeseeseeseaseaserees Corby Dear Capital ONG oo... ccc ccccccccsccsscssecsssesccsscssecseccsesesessessccsescsecsecsseeatessesececeseseetenseeresaees Marie LaQuerre CitIQrOUP, INC... eee eceeceeseececeecseescececsecsecsecsecsessessecsesaecaesateeecaessesaeseesatsateaseassaesaterees Karla McKenna CLS Bank... ccccceccessesssseececeecseescsecsecsecsecsecsessessecseseesaessecaeeeecaecaecaesseseeeeseeseaesaesaserees Ram Komarraju COMEXXUS, INC. .....eeecceceseececcececeecsececeecsecaecsecsessecsessesaecaecaeceecaecaesaeceesaeeeseeserseaesaeerees Michael Davis CONEXXUS, ING. oo. ccccceccccscessessecsscssecseccsecsecsecssecsesseecsessaecsesssscaesssessesaeesaesaeseseaseaees Delap LLP .......c ce ccecccccccsecsecessecsessecssecsesssecsesesescsecsessaeceescaeceescessasssessaeseaseaesessseassaees DelUXe COrporatiOn oo... ccccecessseeseeseeteeeeeeessesseseeeeseeseesessesseseeseeeeeeeseeeneseneeeeeeens Diebold NiXCOrF .........cccesccsccessessccsssssecsesssessecceessecessaeseessseseeesseseseseesaeserssesersserssates Discover Financial S@rviCes............ccccecccceessesceeesseeeeceecseeecaeeacececeecseeesaceesaecaseetateeees Gray Taylor Darlene Kargel Angela Hendershott Bruce Chapa Michelle Zhang OCUITENCY oa. ceceecececeececeececcsceeceecsceecsesecaesecsecaesesaceecaeeesaecetaeceeeesaeeesaeeesaeeeteeetesseneesaees David Wen Federal Reserve Bank ........ccccccccccccsesseessesccsecsecsecsecsesseceseescsecsecseseseaseeseseessaeseeerees Mary Hughes Federal Reserve Bank ........c.ccccccccssscesseseeseesecsecsececseeeseeseeecaecsecseeseseseeseeseessaeseseeees Janet LaFrence First Data Corporation ......cccccccccccescccscesscescesseesecsecssscsseeeceeeenseeseeessecesesesseeeneeeaees Andrea Beatty FIS voecccccccscccsccssccseccsessecssecseccssecsessesesecsessaecsescsssssecsessaessescaeseescsessasessecaecsussnessasseaeeates Stephen Gibson-Saxty FISCLV oo. .ececceccecesccsecseeseeseeseeeeeecaecaesaecaecaeceeeeececcaeceesaeseeceseeeceecaecaeceeeeseeseeseeseaesaseaseeees Dan Otten FIX Protocol Ltd - FPL occ cccseesceceeceeceenessesseseceeeeeseeeessessesseeeeeeeeeeeeeeeseneseeeeens Jim Northey GiIDAL CO... ee eeeeeceeeeeceeeececcsceceeeseeeseeecaeeecaceneaevseeesseeecaececeeeessssesesseseceeeacersarsasieeeenees Harland Clarke ........cccccccseccescssessssessecsecsecsecsecsessecsesececseeseeeecessesseseseseeeseeseesereseeeeees Hewlett Packard... .ccccccccccsesssssesecsecseceesecessecseseceeseesseeecsecseceeeeseseesseeseeeeaeeeseeees IBM Corporation........cccccccccsscesccscesccsecsessessecsessecsecsecsesseseeessaecsesaeseesaeseseaseeseeseaeeatees Independent Community Bankers Of AMETICA ...........:.cceceseesesseseeteeeeseeeseeessesseeseees Bruce Welch John McCleary Susan Langford Todd Arnold Cary Whaley TINGONICO oe. eeeececeeececescesccseecseeesecsecseceesssececcseceseeseecseceessecceecssessesseseaeseeseseecseseeeneens Rob Martin SITCo oeeccccecccccsecssessecseceseceeecsecssessecsseceesesececcsecssesseecseceeseeccseseessesseseeseeeeaeesseseeeneees Jason Brasile J.P. Morgan Chase .....ccccccccccseseneenecceceeeceeneenecsesseceeceeaeeaeecessesaesaesaeeaeeaeeeseeseaeeeeeees Roy DeCicco KPMG LLP ue. eeeeececcecesceccsesseneesesesacecaeeecaeeesseseesesaceecaceecaeeassersenessceesaceesaesasesaeseees Mark Lundin MagTeK, INC. 2... eeecceceeceeceeteeeeeecsecaeeseceeceeeeeeecaeceecaecaeeeseeseeecaeseeceseeseeseeserseeseaeeaeeeees Roger Applewhite MagTekK, INC. .......ccecececeesceseceeceesececeseceseneceeecseccseceseaeseecaesneseeesaeseessaesenssanesneseeseaees Mimi Hart MasterCard Europe Spr ........cccccescccsccsscscessecsecseccsecsescsecseeeeeeseeescsecseeseesseeeeenees Mark Kamers NACHA The Electronic Payments ASSOCIATION ..........c:cccecceceeseeteeteeeeeseeseeeeetetseteeeeees Priscilla Holland National Security AQ@NCY.........ccccceccccsccscsscesseeseesecessesseesecseeetsesseesessecsseseesseeeeeaee Na@utiIUS HYOSUNG....... cc ecccccesecsceseeesecsecesecceceeessecsecesecesscseceeessseesecsessseseeeseseeeenseeaees NCR Corporation .......cccccccccessecsscssccsecsescsecseccssccsessescsesescsecsescsesssessessaesassaeseeesseesaees Office of Financial Research, U.S. Treasury Department ...........ccccccccesseteeteeeeeees PCI Security Standards Council .......ccccceccsseseessneceeeecceeeeseesenerseesseeeseeeseesseereeseeas Paul Timmel Joe Militello David Norris Justin Stekervetz Troy Leach ROULCONE LA... ce eeeeececesscssesceteeseesecsessecsecseeseeseeeessessecsecsecseeeseeecsesseceeessessesseaeeneeaesaserees ROULCONE Ln... eeceecccescesceeeteesessecseesecaecsecseeseeeeesecsesaecaeeseeeseeecsesseceseesesseeserseneeseeseerees SWIFT/Pan AMETICAS 00... ccecceeseeseneceeceecseceeecsecseceecaecaecseesecsecsecseseesaeeseeaseeseneeaserees SYMCOM ING. 0... .eeeececescesceccececeececeecseceecsecsessecsecsessecsesaesaecaeseeesecaesaesseceeseeeeseassesaesaseeees Chris Jenna Frank Debbi Irving Wolfe Vandriessche Fitzpatrick TECSEC Incorporated 0.0... ccc cceccecsscssscsecesseeseceessecseesseceeceeeesesseeseceeseseceesseeeseenes Ed Scheidt The Clearing HOUSE... ececeeeseseesecceeceeceenesecsecsecaecaecaeeaeeaesaesaeeaesaeeaeeaseaseeeeateasees Sharon Jablon U.S. Bank... ee ccccceccccceccsceeceecsenecseecsceecseeecaeeessecsesecaeeecaeeecaeaeneceeseseeeesaeeesaeseesesaeseees John King U.S. Commodity Futures Trading Commission (CFTC) ......cccceecceteceeteteeeneeeteees Robert Stowsky USDA Food and Nutrition Service oo. e ei ceeeeesesseeceeceeseeeestessesseteeeeeeeeeeseeesaeseeseees Kathy Ottobre VaAMtiv LLC ooo. eeecceecececeseecceecceecsesececeececsesaeceseececeesaceesaceesaceeseesaceesaceesaeeeseeaseetaeeetaes VOErIFONE, INC. oe ee eeccecceccsccsecsseeesecececsecseenecsessecsecaecaecaeeaeeaessecseseesaeeaeeaeeeseessaeeeseess VISA oe cecceccccceceesceseneceeceecnecececsecsecsecsececsecaeessenecsecaecaecaecaeeaseaessecsecaeeaeeaeeaeeeesaesaeeeseees Wayne Fueling SYStems ........ceeeceececceceeceenecneesecsececaecaeeaeeaessesaeseesaeeaeeaeeeeeaesateesees Gary Zempich Dave Faoro Kim Wagner Steven Bowles Wells Fargo Bank ........cccccccccscessecsecssssscseceneessesseesseceeseseceeseeessecseesseceesesecesenseeaeenes Mark Schaffer © 2017 ASC X39, Inc. — All rights reserved vii ANSI X9.24-1-2017 At the time this standard was approved, the X9F subcommittee on Data and Information Security had the following members: Dave Faoro, Chairman Organization Represented Representative ACI WorldWide .........ceccccecececesceseeseeceecsceecseeecaeeecaecassecaeeecaecesaecesaeeeccesaecesaesesiesateeaeees Doug Grote ACI] Worldwide .......ccccecceccescesceceteeeceseeeeesseeceeeeececeseeesessaseeceeceeeceeessessessecaeeaesaesaeenes Dan Kinney ACI WorldWide uu... ccc ccccccseccsesssccseessecsecssccseecssessessecsssesecsacessecsesssecsasesseseeasecsees American Bankers ASSOCIatION............ccccccccscesccssecsscssecseessecsecacessecsesaesseseaecseesaeesaees American ExpreSS COMpany.........cccccccccsscsscssecssecsscssecsecescesesseeeseecsesaseeescaessessaeeaees American ExpresS COMpany.........ccccccccccsscsscssecssecsssssessessseceesseeecsecsesaeseescsessuseaeecsees American ExpreSS COMpany ........ccccccsccsscsscsscseecsesssecessseceesseeecseceeseassessatsaeseatesaees Bank Of AMETICA oo... cc eccccccccsescctsetecsecsecsecseeseeseesecsecsesesseeeeseeseseessssessessesesesaeeneees Bank Of AMETICA .........cccccccescsscsssecssecsecseessesesesseecseceecsessescaeseesesescsesseseassaeseaeseessaeesates Bank Of AMETICA «0.0... ccccesccsccssecssecstesscesecsscaeecasesssesecseseaecssseseccsscssseaeesasesecseesseecates Bank Of AMETICA ........cccccesccsccssccssecssessccsecsscsseecsecsscssecsscaecsaeaeecsecseseaeesseeseeeesseecsees Bank Of AMETICA ....... ccc cccescccccssccssecseessccsecssesesssecsscssecsacaecsscseecsecsesaeessecseeeesaeecstes Bank Of AMELICA oo... ee eecceccecceseeneeeeseceeeeeceeecenecaeceeeeeteseaceaseeseseesnesesnecneseesereaeeneens Bank Of AMETICA ....... cece ceccceccsscessecseenseceeceeceseecsecseeesessescseceeseseccsecseessesnseeseseeseeensees BlackBerry LiIMited ........... ccc ccccscccsecsscssccsecseccseecsecssessessessaessescsescsecsesesssseeeseseseneessees BlackBerry LiIMited ...........ccccccccscccsecsscssecsecsesseecseceessessescaesescaescaecsesssssseeeseseseaeesstes Blackhawk Network ........::cccccsccssccssecsscssecsecsseseecsecesessesessaeseessseecaeseseassessaeseseneesaees Bloomberg LP oe. secseccecsseeeeceeesecneeeceeceeceeeeeeeseesaeeecceseeseeseseseseeseeseesesaeseesrsaeeneens Julie Samson Tom Judd Farid Hatefi John Timar Kevin Welsh Amanda Adams Peter Capraro Andi Coleman Lawrence LaBella Will Robinson Michael Smith Daniel Welch Daniel Brown Sandra Lambert Anthony Redondo Erik Anderson Bloomberg LP oo... .ecceccessccsccscesecseeecsecsecsccseeseeeceeeceseeseeseeseeceeseeseeseessesesseseeseecneeneens Corby Dear Capital ONG... ecccccecsecseeccecesecsecsessessesaceeceeceeecseeesesseseeceeseecaeeesesesseseececaesaeenees Marie LaQuerre Capital One... ccccccccccecseeseessesessecsecseseeseseeseessesceeseeeesseseseesaesaeeeseseseseessesaesaeenees Johnny Lee CIPHerithM oo... cece ccsccsccssccssceceseecsecseccssessssecsesessessecsasaecsessaeecaessssesecseseaeeseseaeeeaes COMForte 21 GMDH 0.0... cececescesccsecsecseeeeeeeeeceeeceeceeeeeeeseseesesesesseseeseeseseesesaesaeeaees COMForte 21 GDH 0... ceecccsscesccseccsecssccseessecsesceeeseecaessessaeseessaescesssesssessessaeseesesesonss Communications Security Establishment ........ cc cceecseseceeecceeenesetetseteseeeeeeeeaeeee Communications Security Establishment occ eeeeneecceeecceeenessetesseesaeeeeaeeeeaeeees COMEXXUS, INC. oe. .ecccccececccessecesecessecsseccsuecsesessecsuecceuesesecessecsuescauescssecesesesessnseseratenseees CUSIP Service Bureau uu... ccccccccceccsccssccseessecseceeeessecsecssccsecsaceaeccaecssccsecseceaeesssesecenes Delap LLP uo... cccssecsscesscsscsscessecseessecsecesessececessesseessecsesessseccsecseeassnsseseceesseensees Scott Spiker Thomas Gloerfeld Henning Horst Jonathan Hammell David Smith Alan Thiemann Scott Preiss David Buchanan Delap LLP oo. eeeecceceecseececceeececseesecsessecaeeeeeeccaesseeeseeseaceaseeseeseeseessesnesesersersaeentens Darlene Kargel Deluxe@ Corporation... cecccccccsccssecssessecsecsseeseccseceeesessescseceeseseccsecesssessseseseesseensees Deluxe Corporation ........ccccccccccecesseeneeseseecceeseeseeeeeeceeeeeneseaceaceecneseesnesessesseseeseesaeeneens Deluxe Corporation .........cccccccccscccsecsscssecsecssscseecsecseecsesessaesescseecsesessasseseseseeseasecaees Diebold NIX ........cccccsccessssessecssecsecssecsecseesseceeeceesceesescaesescsescaesessasseseseseesensesaees Diebold NiXCOrt ........ cee cccecceseeeessecseeneccseceeceeceeeeseecsessescaeceeeeeeecsecnesseeeneseaeseeseaeeneees Diebold NixXCOr$ ........ccccccecceccescesecssetececseesccseeseeecesececesseseeceeseeseseesesssessesseseeseesaeeneens Diebold NiXCOrt ........ccccccccccsccsscessecseessecseccsessecescessecsesseesseceesssescsecseesstessesseseeesseenstes Diebold NixXCOrt ........cccceccecceccesceceeseenecsecseesecseeeeeeceaeeecessneseeceeseeseeseeseesesnesseseeseeeaeeneens Diebold Nixdorf ........ccccccccsccsccssccssecsscssccsecssccsecseecssessessescaecsascaeecsecsesaesseecseeseeaeecates Discover Financial S€rviCeS ..........cccccceccccescescceseenseeseeeccsecneceseccseceesseseeseseseesseenaees Discover Financial Services ..........ccccccecssccssccesscecsseesssesseccscceseesesssessessseeceeccseeenseees Discover Financial S€rviCeS .........c cc cceesecseceseeseeeeceeeseeseccaeceeeeseecseceeseeseeeeeeeeeeeeensees Angela Hendershott Margiore Romay Andy Vo Bruce Chapa Michael Ott Dave Phister Christoph Bruecher Andrea Carozzi Michael Nolte Cheryl Mish Diana Pauliks Jordan Schaefer CCUITONCY occ ecceceseeseneeseeeesceeesceecseeseecsesecaececaeeececnecessessesecaceeeacesnesessesessecaeeeeaeeeeaeeae David Wen Federal Reserve Bannk.........cccccccsssecsenecseceeeeseecsecseeeseeeccaeceeceeessecesseeeeseaeseeeeaeensees Patrick Adler Federal Reserve Bank.........cccccccseseseeseeseeseseetseecseesseesceeeeceeceeseesnssessesseseeseeeeeneens Guy Berg Federal Reserve Bank .........cccccccccsseseseeseeceseseeteesessesseeeseeceeceeseeeeeseeseseseseeseeceeneens Marianne Crowe Federal Reserve Bank .........cccccccssseseseeseeeeseeseeeeesseeeeneseeceeceeceeseeseessessesseseesereaeeneens Amanda Dorphy Federal Reserve Bank..........ccccccccsecssessecsecssesssecsecssessecsescseceecssescsecseeesesseesseseesseensees Mary Hughes Federal Reserve Bank ........cccccccccscssecssscessccsseccsseecseeesssesseccsseceseeseessessessseseeeceseeestens Heather Hultquist viii © 2017 ASC Xg, Inc. - Alll rights reserved ANSI X9.24-1-2017 Federal Reserve Bank .........c:ccccccsccsscsssssesseccseesseceecsaeseeecseseeeseessaeserssaeseeesesersseessaees Janet LaFrence Federal Reserve Bank ........ccccccsescscssceseeseeseesecsesecsecseeeeeeecsesseceeeeseseeeseeseeseneeeseeees Susan Pandy Federal Reserve Baik ...........ccccccecceseeeeeeeeeeecceeeeseceeceaeeeeeeaeceeceeseaeseeesaeseeesiesereseeseees Patti Ritter Federal Reserve Bank ........cccccccccccsscssseseesecsececsecsecsecseeeseescsecseceeessseseeseeseessaeeaterees Daniel Rozycki First Data Corporation ........ccccccccccsccscsscessesecseeeesececsesseeeseescaecsecseceseeseeseeseeseaeseeerees Andrea Beatty First Data Corporation ......c..ccccccccsccsccsscesccsescssccsececcsecesscsecsescsescseeseecaessaesaeseseeaseaees Lisa Curry First National Bank Of OMaha@..........cecccceesseceseeseeseeseeseeeeeeecaecsecseeeseeeeeseeseesaesaserees Kristi White FIS vieccccccccccsccssesscecsecsecsecseesessecsecsecsecsessecsecsessecsecsecsessecseceecesssessessscsssaeeaseasnessesseaees Chelsea Lopez FIS coe eeccccceeeeceeececeecsecaecaeceeceeeecaecaecaecaecaeceeeeecaecaecaecaecaeeeseeeeeecaeceeceseeseeseeseeseaeeaseaseeees John Soares FIS ooeeecececcsccseeccsccecceccsceecaceeceececeeseceecacsecacsesaesacsesaceesaceesaseesacsassecaseceseesaseesaesaseetateeeas Sunny Wear FISOMV 0... eeeccceceescesceesecsecenecaeceseeceecaeceecaeseaecaeecseecsecseseaesaeeeaesereseescaeseesaeseneseesnrserseaees Bud Beattie FISCLV oo. .ceccececcssesccccseeseesesaeeseesecaecsecseceesaeseesaececssessesaecaeeasascescaesaecateaseaseasasenteaeeaterees Dan Otten GEOBRIDGE Corporation ...........ccccceccscsseescesseeecseceecsecsecseeeecaecsecseseeseeeeseeseesaeseesrees Donna Gem GEOBRIDGE Corporation ...........cccccccccccsccssessesscsecsecsecsecsecsecsecsecsessecsecseeeesnesseeaeeates Jason Way GID ACO... eee ceecccecescesceeeeeeceececsecsecaecsecaecaecaesaecsecseceesaecaesaeeeesaecaesaeseesaeeasesseaesaesaeeates Scott Turner GID ACO... cee cececcecescesceceeeeceececeecsecseceecaecaecaeesessecaecaesaesaecaeeeesaecaecaecaesaeeeseeseaesaesaseates Bruce Welch Harland Clarke .......cccccccccccccsssescecseccseceecececceeesecssececcneceeeeeceeesneessesneeseceeeseeeeeeeeeeeaees Joseph Filer Heartland Payment SySteMs 00.0... cccceccecsecesseeseseeeteeeeseeeesessesseeseeeeeeseeeenesaeeeeeeens Scott Meeker Hewlett Packard .......cccccccsccscssseesecsecsecseesessecessesececseeseeeessessecsesseceeeeseeseesenessseeees Susan Langford Hewlett Packard... .ccccccccccsesssssesecsecseceesecessecseseceeseesseeecsecseceeeeseseesseeseeeeaeeeseeees Luther Martin Hewlett Packard ........ccccscsssccscssccsessecseeseesessecsecsecsesseceseeseesssesseseeceseeseeseesessaesaserees Terence Spies IBM Corporation ........cccccccccccccsscsscssccssccsecseecssccsseseecsecsesaecseecssecaeessscsessessaeeneecaeessens Independent Community Bankers of AMETPICA .........ccececcccseesseeteeteecseeseeeeecseeeeeneess INQENICO eee eeeeeeeeeceeeneeneesceseeeeseesesaecaeeaeeaecsecsesaesaeeaeeaeeaeeeeeaeeaesaeseseaeeeeeaseaeeaeeaeeatees TNQENICO eee eeeeeeeeceeeneeneesceseeeeseesesaecaecaeeaecsessesaesaeeaeeaeeaeeaeeaesaesaeeaseaeeeeeaseaeeaesaeaeees Todd Cary Rob John Arnold Whaley Martin Spence ITS, Inc. (SHAZAM Networks)........ccccccccccecceessessssececeecsceeeeceeesesseneseceecaeeesaesesereeseees Manish Nathwani J.P. Morgan Chase .....ccccccccccesesesecseceeseececnecnececsesecsecaeeaseeesaeceecaecaseaeeeseeseeseateases Bruce Geller J.P. Morgan Chase ........cceccccecseccceeeesceeesceeceececeeceeeecacecacesaceesesaceesaeeesaeeesaeeeteesateetaes Kathleen Krupa J.P. Morgan Chase ......cccccccccsssesessesecsscsecseceecsecsecsececaecaecaeeaessecseseesaeeaeeaeeeseessaeeeseees Jackie Pagan K3DES LLC... ec cecccccccecceneeneeeesececsecsecseesesseesecsesaecaeceeeeeeeecaecaeeeseeseeeeeseeseeeaeeeserees Azie Amini KPMG LLP ooo. ceceeccesceceeneeteeseceeseecaeceeeaeeeeeeeeaesseseecaeceeeeeeeecaesaeseeeeeeeeeaseeeeneeaseaseeens Mark Lundin MagTeK, INC... ccc cccccsccscesseeseeecssecseceseccecesessesseceseceeecseceeeeeeesesseeseseeeseesseeeeeeaees MagTeK, ING. ...... cc cccccccesecsscsssecsecssccsececcsecseccseccsecsessaecsescseceecessaesessaeeeesaeesseseeesaees MasterCard Europe Spr... cc cccccsccsscsscssesecseesecsecsecsesseeeesecsecsessesseseseeesesseseeeeees MasterCard Europe Spr) .....cccccccccccccsesssesseseeseeecsecsecsecsseeessecsecsessseseeeseeesnesseeseeeees MasterCard Europe Spiro... ccccscccsccssccssessecsecssccseccsecsecsesssecssessecseceeeseteseseaeenees MasterCard Europe Spr .....c.ccccccescccsccsscssessseseeseccsecsssesecseeeeeessesscecseesetsnesseeeaees MasterCard Europe Spr ......cccccccescccscsssccscesseeseeseccecseecsecseeeseesseeescsecssessetenseseeenees Jeff Duncan Mimi Hart Mark Kamers Joshua Knopp Larry Newell Adam Sommer Michael Ward National Institute of Standards and Technology (NIST) .........:ccccceseeseeseseeeeeteeseeeees Elaine Barker National National National Na@utilUS Na@utilUS Institute of Standards and Technology (NIST) ........ccccscsccseeseeeseeeteeseeeees Security AGENCY... cc ceccecceceeteecseeeeeeseeeeeeeeeeeeeessesseeeeseeeeeeeseeseesaeeeseeees Security AGENCY... eecsescecceceetseeeeneesesteceeseeseeeessesseeeeeeeeeeeeseeseaeeaeeeeeeens HYOSUING.......ceeeceseeteeseeseeseeeeseeseeeeeaesseesesaeeaeeaeeeeeeessesaeseeseeeseeaseaseesneeaeeens HYOSUING..... eee eccteneeseeeeeeeeseeceesessesseeseeaeeeeeceeeessessesseseeeeeeeeeeseeseneseeseens Lily Chen Mike Boyle Paul Timmel Joe Militello Jay Shin NCR Corporation .......ccccccceccsccssescsceecsceecsceecaececeececeesacsesaseesseasecesseseseesaseesaseesersaserees Tanika Eng NCR Corporation .......ccccccccccssecsecsscssscssccsecsecescesesseccsecsescseceeeessesssessscseeseesaeesesenseeaees Charlie Harrow NCR Corporation .......ccccccccessecsecssesscsecssecseeessecsecsescsecsesssecseeeneeessesseecsseseesseseneeenees David Norris PCI Security Standards Counc ........ccccccecceseseeseeeeeeeeceeseeeeceeseseeeeeeeeeeeeeeeeeaeeeseeees Leon Fell PCI Security Standards Council .........cccccccccseescesecesseeecteceeeesseeeensesteceeeseeeseeseesaees PCI Security Standards Counc .......ccccccceseseeseeteeeeeceeeeeecnessesseeeeeeeeeeeeeeesaeeeeeeees RSA, The Security Division Of EMC uu... cccccccscscesecceeecsecsessessecseceeseseecsreeseeeees SafeNet, INC. oo... cccccccccssccecsssecesseccecssecesseececsssesesseececssececssececsssesesstecceeecessseesesseesenss SOE CUrILY INNOVATION ooo. ee eee eeeeneeneceeceececceeesseesesecaeeaeceeecessessessesaeeeeeeeeaeeaseneeseeeees Troy Leach Ralph Poore Steve Schmalz Amit Sinha Mark Etzel SO@CUrILY INNOVATION 00... eeeececceceesenseseceeceecsecseesecsecsecsecaecaecaecsessessesseseeseecaseaseeseneeeserees William Whyte SO@CUrIty INNOVATION 00... eee ecececeesenseneceeceecsecseeseesecsecsecaecsecaeeeecaessesieseecaeeeeesseeseneeeserees Lee Wilson Se@CUrity INNOVATION 0... ee eececcecseesctseneceeceececseeseesecsecsecaecaeceeeaecsecaesaessecaeeseeaseeseneeateeees Zhenfei Zhang © 2017 ASC X9, Inc. — All rights reserved ix ANSI X9.24-1-2017 TECSEC INCorporated ........cccccccscssccssessecseccsccsseessesesseessecseccsecsatssssssesaeesseeeceaeesreens Ed Scheidt TECSEC Incorporated ........ccccccccecsesseseeseeseeseeeseeceseseesseseceeceececeeesesesesseceeseeeeaeeaes Dr. Wai Tsang TECSEC Incorporated .........ccccscsccccssssssessesseesseseecesesseessesessessesceecesessessesesaesaesaeeaes Jay Wack Thales UK Limited .........cccceceescssccecessesesseesseeeeeceeceseeesesseseessessescessesesesaessesaesaesseeees Larry Hines Thales UK Limited ...... cece cccccccssccsecssecsecssccssesseeseessesssecsecsescsaesaeessecaessaeeseseeesueess The Clearing HOUSC..........ccccccccccsesseeseessecsecsecsseeeeseceseessececesecseeenesteecseesaeceeseeeetreees TTUStWAVE oo. eccccececseesseseceeececsseeseesseesseeaeceeccsecuesseeesesssecssceeeceessessesaeseaeseceeeeaeeegs TTUStWAVE ...ceecccceeeesseensesseceeceecsecseessessaseaeceeccaeceuesseeesessaecaeceeeeceesneseesaeseaeeteseeeeeeegs U.S. Bank... ccccesccscssecsscssessecseecssecsessessseseessaeseeecescsessessaeseesssescsessesssesessaeserseneessees U.S. Bank....ccccccccccsesccsccsecsecsecsecsecsecsecsessessessecassassseceecesseseaseaseeseescasesesseseeseesarsatseeees James Torjussen Henry Farrar John Amaral Tim Hollebeek Stephen Case Peter Skirvin Vantiv LLC ooo. eeccceccccecesceeesceececcceececeececsesaceesaceeseeceseeceseesaseesaseeserseseeseseesseesaseesareass Jeffrey Singleton VAMtiV LLC occ ccccecceseescescescesceeeeseeseseseeseececececeseeeseeseceeseeceecneeeesessesseceeeaesneseenes Bill Weingart VAMtiV LLC occ cccecceeseeecesceeceeceeeesesseeeseeeeeceececeeseeeesesseceeseeceeseestesesesseceeeaeeeseeees Gary Zempich VANtiV LLC occ ccceeceeceeeeeeeceeceaeeseeseseeeeseeceeceeceeeeseeesesseceecneceeeeseesesesseceeceeeeaeeaes VeriFONG, INC. oo... ecccceccescescescesceeceecesceeeeeceseeseesaeseeeceesessesesaesaescensesesesaesesatsatsaesees VeriFONE, INC. oo... eccccescesceeecceeceeceeceeceeceeceeseesseceeceeeeeeeseseesesaescenceseeseesesrsaesaesaesees VeriFONE, INC. oe. ceeccceceeseeeecceeceeceeceeceeeeeceseeseseeseeeeeseseseesesaesceeceseesesaesrsaesaeeaeeees VELIFONE, INC. oo... eeceeesssceeesscccesscceessseeessessessccccsueecesssesesseecesseccesssesessesessteeceaueccesates VErIFONG, INC. cocci cece ccccccccccssccccesseccesseecesecceeeccsesseesessseceessccesueceesseesesssecetseecennees VOrIFONE, INC. oe. ceececeeecescescescesceseeeceseeeeeeeeececececseseeseeseceeceeceecsesessessesseceeeaesesaeeaes VISA. cecccccccsceeesessessccsecsessesecsessessaeeecssesessesseseesseseessessessesseseessesaescesseseesesaesaesaesatsaesaes James Zerfas John Barrowman David Ezell Dave Faoro Doug Manchester Brad McGuinness Joachim Vance Shahzad Khan VISA. ce cccccccsceseescesesccsesseeseeaesesecsaeeecsscessessessesseserseessessesseseessesaescescesesesaesrsaesaesaeeaes Kim Wagner Wayne Fueling SYSt€Ms...........ccccccsecsccssccsecssccssesecssessesseecseesescsssseesseecasesaecsessaeessenes Steven Bowles Wells Fargo Bank .........ccccccccccscccssesecseessccseceseccseesecseesseessececeseccseeseeseesseesaeseeseeeeeeegs William Felts, IV Wells Fargo Bank .........:ccceccecceceesseecsseeseesceseeeceeeeessseseeeeseceecnecneeseesesesessecneeaeeateaeeaes Phillip Griffin Wells Fargo Bank ......... cc cecceccecseseeceseessesceeeeeeeeseessseeeseseceecnesneeseeseseesessesnesaeeaeeaeenes Jan Kohl Wells Fargo Bank .........:ccceccecsecseeseececeeeeeeeeeeeeseeceeceeeeeseeseeseesesaeeceseeseeseesesersesaesaeeees Garrett Macey Wells Fargo Bank .........cccececsecseneeeceeeseeeeeeseeseeceeceeeeeseeseeseesaesaeeceteeseeseesaesneeaeseeaeeaes Kelly O'Donnell Wells Fargo Bank .........:ccececcecsecceeceeeeeeeeeeeseeseeceeceeeeeeeeseseeseseeceeeeseeseesesneeaesieeaeeets Mark Schaffer Wells Fargo Bank .........:ccccccecceccesseeceseesseeceeceeceeceeeeseeeeseeseceeceeceeetseeesessesseceecesneeeeaes Jeff Stapleton XYPRO Te@CHNOIOGY ........cccccesscscssscscssessessesseseceseecssessessesecsecsecsecssessesessessecaecseeaessaeaes Steve Tcherchian Under ASC X9, Inc. procedures, a working group may be established to address specific segments of work under the ASC X9 Committee or one of its subcommittees. A working group exists only to develop standard(s) or guideline(s) in a specific area and is then disbanded. The individual experts are listed with their affiliated organizations. However, this does not imply that the organization has approved the content of the standard or guideline. (Note: Per X9 policy, company names of non-member participants are listed only if, at the time of publication, the X9 Secretariat received an original signed release permitting such company names to appear in print.) At the time this standard was approved, the X9F6, Cardholder Authentication and ICC's group which developed this standard had the following active members: Scott Spiker, X9F6 Chairman Darlene Kargel, X9F6 Vice Chairman Andrea Beatty, Technical Editor John Spence, Technical Editor Organization Represented Representative American Express Company ..........cccccccccesesceseeeeseeseseescseeesaceeeaecaneesaeeesaeeesaeeetaeeesereas Alan Fong Bank Of AMETICA....... ce ceececcesecceeesessenesseneeseeeceeenessesevsssevsceesaceecaenesnesssnersseesaceesaeenenens Andi Coleman Delap LLP ooo. eccecccccsccsseescssseeseessecsecscsecsecsseesseesseesecseseseceeeeseessesseseseseessseseeenees David Buchanan X © 2017 ASC X9, Inc. - All rights reserved ANSI X9.24-1-2017 Delap LLP oo... eceeceeeeeeceeceseeeeeeeeeseeseeseseeeeesessesesececaeseseeseesecesesecaesersersneeneeas Darlene Kargel Diebold NixOrt..........cccccccscccseessessecsscssecsecsseeesecsecsecsscsseseeessesessessseeeessseceesesesatenaees Bruce Chapa Diebold NixXCOSF..........ccccccccsscessssesssseesecsecseecsecesessesessessessessesessesaessesaesaesaesaesnessesaeeas Anne Konecny Federal Reserve Bank ..........ccccccccssssssssseseecsesseeececeecsessesaessesseseseseesaesaesaeseesesesaeas Amanda Dorphy First Data Corporation ...........ccccccscsssssceseecseeseeeceeceesecececseseseseseseecesaeseeseesesaeeas Andrea Beatty First Data Corporation..........ccccccccccsccsscsscsssccsecsscssececcsessesessscsecsescasesesssessueeessatenaees Lisa Curry First National Bank Of Omaha... ee eeeceeeeeeseteeeeeeeeeeseeeceecseetseeesaeeetaeeaseetaeeetatees Kristi White FISCIV oo. eeseceeseeseeseeseeeceececseceeeeeeessececneceeneeessesseceececnecaecesesessesaesecaeeaesnesnesneeneegs Dan Otten FULUIOX .....ceeececsceescesseesesseesnesceesseeseecaeseecsessueecsessessaesseseaesaesesescsessessaesessaesauesessaeeaaees Ryan Smith GEOBRIDGE Corporation ...........cccccececssceceeceeeseeeseeecseeceeeeseecesseceseesaseesaeseseeseneesaees GEOBRIDGE Corporation ..........ccccececcecesceeeeeeseseeeeeeeeesececeeseecesseceseesaseesaeceseeseseeeaees GEOBRIDGE Corporation ...........cccceccessesccsecseessesseseeeceesecseeeeeeesseseseseesaeseeseessesaeeas GID ArCO oo... eeceecceceseesceseescescesecsecseceeeseseseesceeceesesseseassaseesaesaeseeseesseseeseesaesaeseesesaesaeeas GiIDAPCO eee ecceeneeeneseesessenessesececsceescesseressececeececeececeessessssessceesecedeeevesseseesesanes Donna Gem Dean Macinskas Jason Way Scott Turner Bruce Welch Heartland Payment SySteEMs ..........ccccccsccsccsecsscssecsscssecseessscssesessaeesesssesueeeesatenaees Hewlett Packard .........cccccccscsccsccsscssecsecsssscsecsecssesessseseessesssessesssesessaesaesenessatenaees IBM Corporation ........cccccccecssesessesscsssescsecsseesessessscessecesesseessesessessecsesaecsesseeeesesseenes INQENICO Le cece eeesscececeeceteeseesseeeeseceecececseeseeeeeseeseecesaeeaeeesessessesesaeeatenessessesaeeaes John Masden Susan Langford Todd Arnold Rob Martin INQEMICO.. ee eeeseeeeescescesceseceecseeseeeseceeceecsecaceseeseeseseesececaecaeesessessessececaecaeeeesessesseeats INQEMICO.. ee eeeeeceseescescescesecsecseeseseesececeeceecseeseeseeseseesecaecaecaeenessessesseseececaeesesesaesaeeats JP. Morgan Chase ........cccescccccscessesesseeeeeccsceseesseseseessesseseseessessessesaesaessesaesaesaesaees JP. Morgan Chase ........:ccecccccessesceseseeeeeecescesseeseessessessesaesessessesseseesaesaesaesaesesaesaees K3DES LLC. cc cceseeseneresecseeescescesseesseessceesceesacessessssessseesaceesaseesnessenesaanes Steve McKibben John Spence Kathleen Krupa Darryl Scott Azie Amini K3DES LLC... ccccccccceeseeseeseesecceceecseceteessecsecaeceeseseceeseesesessessseseeseeceeeeeseaeenaees James Richardson Maiinsall Trim, INC. ......cccccccccccccssccesscccccssccecsssecessseecessecccsececssstsessstecesusecesseeecesteeeente Norman Cecil National Institute of Standards and Technology (NIST) oo... ceeecececceceteeeteeteneeenes Elaine Barker PCI Security Standards Councl........cccceccceceesseceseeseeceecseceeseesneceeseecneseserseesneeaeens Ralph Poore Thales UK Limited 0... ee ceccccceeceeeeeeseeeeeceeeeeceeseeseeseeseseseeseeseesesiesesiesaeeaesiesaeeaeed Colette Broadway Thales UK Limited... eccccceseessescecesceeesseeseesseeceeeeeseecneceesessesseceeceececaeeaeeaeenesaeed Larry Hines Thales UK Limited... ececcceseeseecceceeceeesseeeeeesseceeceeceecneceeseessesseceeseesneseeeeesnesaeed James Torjussen TTUStWAVE.... see eeeeccceseccececcnessesseseseseccaceeesceeeesassessesecacetsaceeesesiesessesecaeedcaeeseesienesaeeted Tim Hollebeek U.S. Bank wo... cecccccccccsccsseccssecessecseeccssccsecessecesesessesessccseecseessssssesaeceseeecseeesseensesenee VAMNtIV LLC... eee ccccccccccesecssccssecsccecssecsecsaeccssssecsaecsessaessessessesecaessascsesaesaeecsesaesneeeass VErIFONE, INC... cccecccecssscecsscecesscecessseceseseccstecesseecesssececseeesesstecesssecesseecersatesersesenea VErIFONE, INC. ......cccecccesseseecsseecesscecesssecesseeecesstecesseecesssecesseeecesstecesseecesseecensatesssseeenes VeriFONE, INC... ccc ccccsccecsscecessscccsesecccsesecsssesescececssececssseserssesescesesrecesaversnsesenss Stephen Case Gary Zempich Dave Faoro Doug Manchester Joachim Vance VISA ceecceccssesesessesessceeecceeeccnecsesessesevsccaceecaeaeeesasseseceesaceesaceeenesaeeesaeecaeeecaeeeenesaenesaeerta Adam Clark VISA ceccccssessesessesessceeeceneecceecsevsesesavsceaceecaceaecesassessceccaceesaceeseessenesseecaeedcaeeeenesaenesaeeeea Shahzad Khan VISA voecccccccccceccsecsecseesesseeeeeseeecseseceeseasesseseesaeseeseessaseaseesaesaeserssessesseseesaesaesaeseeseesaesaess Michael Stefanich VISA coecceccccccccsscsseesecesccsecssecseceseeseeesecssecsesesecsecssecseessesesessesesecsessesssecesesscseessessseeneesges Wayne Fueling SySteMs ....... ce eeccceceeeeeeceeceeeeeeeeceeceeceececnesessesseceeceesiesaeeesseraeraeed Wells Fargo Bank........cccccesssesseeeecceceeceecsseeseeesseceeeeeseesneceesessesseseeceecieceeaeeesneraeed XYPRO Technology .....cececceeeseseeseesccesceesenecsenecseeeceeeceeeenessenesseneceeeeeeeeseesaenesaeees Kim Wagner Steven Bowles Jeff Jacoby Steve Tcherchian This document cancels and replaces the 2009 version of X9.24 Part 1. As part of the ANSI 5-year review process, this standard underwent significant modifications that resulted in an extensive rewrite. It reflects updates in key management security requirements, includes AES algorithm use, and leverages advancements in hardware devices used for protecting cryptographic keys. Implementation details for TDES and AES DUKPT have been moved to part three of X9.24. © 2017 ASC X9, Inc. — All rights reserved xi ANSI X9.24-1-2017 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques 1 Purpose This key management standard, utilized in conjunction with the National Institute for Standards and Technology Triple Data Encryption Algorithm (TDEA) (see Reference 1) and the Advanced Encryption Standard (AES) (see Reference 5), is used to manage symmetric keys that can be used to protect messages information in a financial services environment. and other sensitive The security and reliability of any process based on AES or the TDEA is directly dependent on the protection afforded to secret parameters called cryptographic keys. This standard establishes requirements interoperability of keying operations. and guidelines for the secure management 14, and 16), for encrypting Personal Identification Numbers (PIN) (see Reference for encrypting other keys, or for other purposes. 2 and application-level Such keys could be used for authenticating messages (see References 11, 10), for encrypting other data, Scope 2.1. General This part of this standard covers both the manual and automated management of keying material used for financial services such as point-of-sale (POS) transactions (debit and credit), automated teller machine (ATM) transactions, messages among terminals and financial institutions, and interchange messages among acquirers, switches and card issuers. This part of this standard deals exclusively with the management of symmetric keys using symmetric techniques. Requirements for symmetric keys protected by asymmetric keys are addressed in X9.24-2. Any requirements stated in this part are not meant to invalidate the requirements provided for in Part 2. This part of the standard specifies the minimum requirements for the management of keying material. Addressed are all components of the key management life cycle, including the generation, distribution, utilization, storage, archiving, replacement and destruction of the keying material. An institution's key management process, whether implemented in a computer or a terminal, is not to be implemented or controlled in a manner that has less security, protection, or control than described herein. The intention is that if two nodes implement compatible and secure versions of key management methods, key identification techniques, and key separation methods accordance with this part of this standard, they will be interoperable at the application level. in Other characteristics may be necessary for node interoperability; however, this part of this standard does not cover such characteristics as message format, communications protocol, transmission speed, or device interface. The definition of the DUKPT algorithm is addressed in X9.24 Part 3. Information contained in previous versions of this standard related to the implementation of DUKPT has been moved to that standard. 2.2 Application This part of this standard is applicable for institutions implementing techniques to safeguard the cryptographic keys used for the authentication and encryption of messages and other sensitive data. For example, this applies to institutions in the financial services industry implementing References 10, 11, or 18. Mandatory standard techniques and procedures are indicated by the word 'SHALL'. Guidelines are indicated by the word 'SHOULD'. 12 © 2017 ASC X39, Inc. — Alll rights reserved ANSI X9.24-1-2017 3 References This part of this standard SHALL be used in conjunction with the following publications. 1. NIST SP800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher 2. ANS X9.82, Random Number Generation, Part 3: Deterministic Random Bit Generators ISO 13491 - 2016 - all parts, Financial services — Secure cryptographic devices (Retail) ANS X9.24-2, Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys FIPS 197: Advanced Encryption Standard (AES), November 26, 2001 NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: (December 2001) Methods and Techniques NIST SP 800-38C: Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality (July 2007) NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (November 2007) ANS X9.24-3, Retail Financial Services Symmetric Key Management Part 3: Derived Unique Key Per Transaction (Ballot Note: This is to be published in 2017) The following publications are applicable and may be referenced in this part of this standard. 10. ANS X9.8-1, Personal Identification Number (PIN) Management and Security 11. ISO 16609, Banking — Requirements for message authentication using symmetric techniques 12. ISO 7812, Identification cards - Numbering system and registration procedure for issuer identifiers 13. ISO 8583, Bankcard Originated Messages — Interchange message specifications — Content for financial transactions 14. ISO 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher 15. ISO/TR 14742, Recommendations on cryptographic algorithms and their use 16. NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: Authentication (October 2016) The CMAC Mode for 17. ANS X9.102-2008, Symmetric Key Cryptography For the Financial Services Industry - Wrapping of Keys and Associated Data 18. ANS X9.119, Retail Financial Services - Requirements for Protection of Sensitive Payment Card Data Part 1: Using Encryption Methods © 2017 ASC X39, Inc. — Alll rights reserved 13 ANSI X9.24-1-2017 19. ISO 11568-2, Financial Services - Key management (retail) — Part 2, Symmetric ciphers, their key management and life cycle 20. NIST SP 800-57: Recommendation for Key Management — Part 1: General 21. ANS TR-31, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms The versions listed were current as of the publication of this document; however, these documents are routinely updated and reaffirmed. The current versions SHOULD be referenced when using this part of this standard. If a date was indicated on the reference above, there may be a specific section cited. This is not meant to preclude the use of the newer version, only to signify the section was related to this specific version of the standard. 4 Terms and Definitions 4.1 Acceptor see “Card Acceptor” 4.2 Acquirer the institution (or its agent) that acquires from the card acceptor the financial data relating to the transaction and initiates that data into an interchange system 4.3 Advanced Encryption Standard (AES) the algorithm specified in Reference 5 4.4 AES see “Advanced Encryption Standard” 4.5 Algorithm a Clearly specified mathematical process for computation; a set of rules which, if followed, will give a prescribed result 4.6 ANSI American National Standards Institute 4.7 Archived Key an inactive key that is being saved in a secure manner for a non-operational purpose 4.8 Authentication the act of determining that a message has not been changed since leaving its point of origin. originator is implicitly verified 14 The identity of the © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 4.9 Base Derivation Key (BDK) key used in a derivation process to generate initial DUKPT keys. The same key is used by the host to derive the current transaction key 4.10 BDK see “Base Derivation Key” 4.11 BDK ID a 32 bit value that identifies the Base Derivation Key. This was formerly known as the Key Set Identifier (KSI) in the TDEA DUKPT specification 4.12 Card Acceptor party accepting the card and presenting transaction data to the acquirer 4.13 Card Issuer the institution or its agent that issues the card to the cardholders 4.14 Chain of Custody the chronological documentation or paper /digital trail showing the custody, controls, transfer, access, and disposition of the controlled item 4.15 Check Value a non-secret value that is cryptographically related to the key (or component) and is used to verify that the underlying value is as expected. It is possible for different keys or components to have the same check value 4.16 Ciphertext data in its enciphered form 4.17 Cleartext data in its original, unencrypted form 4.18 Component Check Value (CCV) see “Check Value” 4.19 Compromise in cryptography, the breaching of secrecy and/or security. A violation of the security of a system such that an unauthorized disclosure of sensitive information may have occurred 4.20 Cryptographic Key a secret value used in the operation of a cryptographic function such as: a) the transformation from cleartext to cipher text and vice versa b) synchronized generation of keying material c) computation or verification of a Message Authentication Code © 2017 ASC X39, Inc. — Alll rights reserved 15 ANSI X9.24-1-2017 4.21 Cryptographic Key Synchronization the ability for two nodes that cryptographically process a transaction, to determine the identical Transaction Key 4.22 Cryptographic Strength the computational cost of the best-known attack against a given cryptographic algorithm and key size. The cryptographic strength is usually a function of key size, but different algorithms may have a different cryptographic key strength even though their key sizes are the same. See Reference 15 and 20 for guidance about the security strength (i.e., cryptographic strength) of keys used with particular algorithms. The strength of a given algorithm and key size may vary depending on the use of the algorithm. For example, uses with few or no plaintextciphertext pairs may be more resistant to attack than uses with many pairs 4.23 Cryptoperiod the time span during which a specific key is authorized for use, or the time span during which the keys for a given system will remain in use 4.24 Decryption a process of transforming cipher text (unreadable) data into cleartext (readable) data 4.25 Derivation a cryptographic transformation process that is used to derive one value from another value. It is typically used in the context of this standard to derive one cryptographic key from another key 4.26 Derivation Identifier/ Derivation ID a 32 bit value that identifies the specific initial key derived under the Base Derivation Key specified by the BDK ID. This was formerly known as the 19-bit value Device ID (DID) or TRSM ID 4.27 Derivation Key a key that is used to cryptographically compute another key using a derivation process. Normally a single derivation key is used in a transaction-receiving (e.g., acquirer) SCD to derive or decrypt the Transaction used by a large number of originating (e.g., terminal) SCDs Keys 4.28 Derived Unique Key Per Transaction (DUKPT) a key management method that uses a unique key for each transaction, and prevents the disclosure of any past key used by the transaction-originating device. The unique Transaction Keys are derived from a base derivation key using only non-secret data transmitted as part of each transaction 4.29 Double-Length Key TDEA key having a length of 128 bits, consisting of 112 key bits and 16 parity bits, which is typically represented in 32 hexadecimal digits transaction 4.30 Dual Control a process utilizing two or more separate individuals, operating in concert, to protect sensitive functions or information. Each individual is equally responsible for the physical protection of materials involved in vulnerable 16 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 transactions. Dual control ensures that no one individual is able to access or to utilize the materials (e.g., cryptographic key) alone. For manual key generation, conveyance, loading, storage, and retrieval, dual control requires split knowledge of keys among the entities. Also, see “Split Knowledge” 4.31 DUKPT see “Derived Unique Key Per Transaction” 4.32 Encryption a process of transforming cleartext (readable) data into cipher text (unreadable) data for the purpose of security or privacy 4.33 Entropy a mathematical measure of the amount of unpredictable information 4.34 Exclusive-Or (XOR) a mathematical operation, symbol “XOR’, defined as: 0XORO=0 OXOR1=1 1XORO=1 = 1XOR1=0 Equivalent to binary addition without carry (modulo-2 addition) 4.35 Initial DUKPT Key a unique key loaded into an SCD that has been derived from a DUKPT BDK 4.36 Initial Key ID a 64 bit value that identifies the specific initial key derived under the Base Derivation Key. It is a concatenation of the BDK ID and the Derivation ID 4.37 Institution an establishment responsible for facilitating customer-initiated transactions or transmission of funds for the extension of credit, or the custody, loan, exchange, or issuance of money 4.38 Interchange mutual acceptance and exchange of messages between financial institutions 4.39 Issuer the institution holding the account identified by the primary account number (PAN) 4.40 ISO International Organization for Standardization 4.41 Key see “Cryptographic Key” © 2017 ASC X39, Inc. — Alll rights reserved 17 ANSI X9.24-1-2017 4.42 Key Check Value (KCV) see “Check Value” 4.43 Key Component one of at least two parameters having the format of a cryptographic key that is combined using XOR with one or more like parameters to form a cryptographic key. A component is equal in length to the resulting key 4.44 Key Encrypting Key (KEK) a key used exclusively to encrypt and decrypt other keys 4.45 Key Injection Facility (KIF) a physically secure room in which cryptographic keys are loaded into SCDs 4.46 Keying Material the data (e.g., keys, attributes, and relevant metadata initialization vectors) that comprise a complete cryptographic key and its 4.47 Key Separation a process for ensuring that a key is used for only its intended purpose 4.48 Key Set a group of keys that are all determined by a common cryptographic procedure and differentiated by non-secret input to this procedure such that knowledge of one key does not disclose any other key in the group 4.49 Key Set Identifier (KSI) a non-secret value that uniquely identifies a key set 4.50 Key Shares the result of dividing a key into multiple (m) pieces (shares or fragments), such that a designated minimum number (n) of pieces are required to reconstitute the key. Each key share is constructed in such a manner that access to n-1 shares does not disclose any information about the key 4.51 KIF see “Key Injection Facility” 4.52 KSI see “Key Set Identifier” 4.53 MAC see “Message Authentication Code’ 18 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 4.54 Master Key in a hierarchy of Key Encrypting Keys and Transaction Keys, the highest level of Key Encrypting Key is known as a Master Key 4.55 Message a set of data elements used to exchange information 4.56 Message Authentication Code (MAC) a cryptographic value used to confirm that the message came from the stated sender and has not been changed in transit. see References 11, 14, and 16 for further information 4.57 Node any point in a network that does some form of processing of data, such as a terminal, acquirer or switch 4.58 NIST National Institute of Standards and Technology 4.59 Originator the person, institution or other entity that is responsible for and authorized to originate a message 4.60 PAN see “Primary Account Number” 4.61 Parity the result of a calculation of the number of ‘1’ bits in a string of ‘0’ and ‘1’ bits, that indicates whether the number of ‘1’ bits is odd or even 4.62 Personal Identification Number (PIN) string of numeric digits established as a shared secret between the cardholder and the issuer, for subsequent use to validate authorized card usage 4.63 Primary Account Number (PAN) an assigned number, composed of an issuer identification number, an individual account identification and accompanying check digit as specified in ISO/IEC 7812-1, that identifies the card issuer and cardholder an 4.64 PIN see “personal identification number” 4.65 Pseudo-Random Process a process that produces a value which is statistically random generated by a deterministic algorithm © 2017 ASC X39, Inc. — Alll rights reserved and essentially unpredictable even though it was 19 ANSI X9.24-1-2017 4.66 Random a value in a set that has an equal probability of being selected from the total population of possibilities, hence is unpredictable 4.67 Replay the process of sending perpetrating a fraud a message which contains all or part of a previously sent message, as a method of 4.68 scD see “Secure Cryptographic Device” 4.69 Secure Cryptographic Device (SCD) a device that provides physically and logically protected cryptographic services and storage (e.g., PIN entry device (PED) or hardware security module (HSM)). The SCD may be integrated into a larger system such as an ATM or POS terminal 4.70 Sender the person, institution, or other entity transmitting a message 4.71 Split Knowledge a condition under which two or more parties separately and confidentially have information (e.g., key components) that, individually, convey no knowledge of the resulting combined information (e.g., a cryptographic key) 4.72 Symmetric Key a cryptographic key that is used in a symmetric cryptographic algorithm symmetric key that is used for encryption is also used for decryption (e.g., TDEA or AES). The same 4.73 Switch a node that can route data from a node to other nodes 4.74 Tampering any unauthorized modification that compromises the security properties of a device or security container. Examples include insertion of active or passive tapping mechanisms into a device to determine, record, or modify secret data; or the attempt to penetrate or open a security container or device 4.75 Tamper Evident and Authenticable (TEA) Bag the one-time use packaging that is designed in such a way as to make it infeasible to access the contents without detection, and has a pre-printed unique identifier that cannot be changed without detection to allow for authentication. TEA packaging alone may not offer privacy, but rather provides a means to detect unauthorized access. The form of the packaging is not necessarily restricted to a bag 4.76 TDEA see “triple data encryption algorithm” 20 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 4.77 TEA Bag see “Tamper Evident and Authenticable Bag” 4.78 Terminal a device/system that initiates a transaction 4.79 Transaction a series of messages to perform a predefined function 4.80 Transaction Key a key used to cryptographically process the transaction. functions, each key may be a If more than one key is used for different cryptographic variant or derivative of the Transaction Key. A Transaction Key is sometimes referred to as a data key, communications key, session key or working key 4.81 Triple Data Encryption Algorithm (TDEA) algorithm specified in Reference 1 4.82 Triple-Length TDEA Key a TDEA key having a length of 192 bits, consisting of 168 key bits and 24 parity bits, that is typically represented in 48 hexadecimal digits 4.83 Variant of a Key a new TDEA key formed by a reversible process (which need not be secret) with the original TDEA key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key 4.84 Verification the process of associating and/or checking a unique characteristic 4.85 XOR see “Exclusive-Or” 5 Standard Organization The remainder of this part of this standard is divided into these sections. Section 6 describes the environment in which key management techniques operate Section 7 establishes the requirements applicable to key management SectionO specifies key management methods, key identification techniques, and the additional requirements for each specific method Annex A — describes key and component check values © 2017 ASC X39, Inc. — Alll rights reserved 21 ANSI X9.24-1-2017 AnnexB _ 6 specifies requirements for maintaining split knowledge during transport Payment Environment 6.1 General In order to provide insight into key management requirements, this section provides a generic description of each of the entities involved. Transaction processing systems are composed of subsystems operated by one or more of these entities. The method of identification in such systems has considerable effect on the overall security requirements. While this part of this standard primarily addresses transaction-processing systems (e.g., ATM systems, POS networks) using cards as part of the identification process, other applications of this standard are not precluded. 6.2 Cardholder and Card Issuer The card issuer guarantees payment to the acquirer for transactions or services rendered to the cardholder upon proper authentication and authorization of the cardholder, providing that all required conditions have been met. The card serves to identify the cardholder and the card issuer. In addition, the card may carry other information such as period of validity (e.g., the expiration date) and security related information (e.g., the PIN offset). The cardholder and the issuer share a customer’s secret Personal Identification Number (PIN) (see Reference 10) to be used during transactions. The transaction processing system has an obligation to maintain the PIN secrecy while transporting the transaction from the cardholder to the card issuer. Note that the card issuer may delegate responsibility for verification of the PIN to an agent. 6.3 Card Acceptor Organizations acting in this role accept cards to access the cardholders’ account(s) or as a means of payment for goods or services. This may be a retailer, service company, financial institution, etc. The security of the transaction information exchanged with the acquirer is important. Security features may include message authentication (see Reference 11), secrecy of the PIN (see Reference 10), the protection of the sensitive payment data (see Reference 18), etc. This role manages the transaction-originating SCD, into which the payment information (e.g., PIN, PAN) is entered by the Cardholder. 6.4 Acquirer Organizations acting in the role of acquirer provide transaction processing to card acceptors and submit transactions into interchange. For some transactions, the acquirer may authorize a transaction acting as an agent of an issuer. In other cases (e.g., the transaction value exceeds a certain threshold) the transaction information is sent to an issuer or its agent for authorization. For the acquisition function, the acquirer needs facilities that provide secure processing for the translation of PINs in node-to-node systems, message authentication for transaction exchanges, etc. For combined acquisition and authorization functions, the acquirer needs security facilities to satisfy the requirements of the issuer it represents. 6.5 Switch Organizations providing services of routing a transaction message to one of multiple destinations. Other terms for this function include, but are not limited to, Interchange, EFT Networks, Processors, Payment Brands, Payment Networks. 22 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 7 7.1. Key Management Requirements General Cryptographic algorithms used to protect information are not interoperability. However, the encryption key must remain secret. secret and are widely available to provide Key generation, storage, loading, transport, use, and destruction are points at which a key management strategy is established and enforced to ensure the secrecy of the keys. The impact of a compromise of a given key should be taken into consideration when deciding the strategy for its management. It is necessary to employ mechanisms that detect or prevent the use of modified or substituted keys, or the replay of keys. This section includes general requirements that apply to the management of keys. 7.1.1 Dual Control and Split Knowledge The management of a cleartext component or share throughout its lifecycle SHALL ensure dual control and split knowledge of the resulting key. Throughout the lifecycle of a key, an individual SHALL never have (or have had) access to all cleartext components or shares necessary to form the key. Each person or group of persons (e.g., Custodian) responsible for each key component or share SHALL have received adequate training and signed an acknowledgement of the responsibilities to keep secret the key component or share entrusted to them. The chain of custody for each cleartext component or share SHALL be documented and such documentation maintained. Each person or group of persons responsible for injecting cleartext keys from one SCD to another SHALL have received adequate training and signed an acknowledgement of the responsibilities entrusted to them. 7.1.2 Permissible Key Forms Cryptographic keys SHALL only exist in one or more of the following forms: 1. Ina Secure Cryptographic Device (SCD) as specified in Section 7.2 below 2. lf encrypted and outside an SCD: i) as acryptogram of the key that SHALL have been created inside an SCD using a TDEA or AES Key Encrypting Key and satisfies the key block requirements in Section 7.4 ii) as cryptograms of key shares or key components, where the cryptograms SHALL have been created inside an SCD using a TDEA or AES Key Encrypting Key and satisfies the key block requirements in Section 7.4 iii) as cryptograms of the key, key shares or key components, where the cryptograms SHALL have been created in an SCD using asymmetric cryptographic techniques in accordance with Reference 4 3. If not encrypted and outside of an SCD, a key SHALL exist only in the following forms: i) as two or more full length key components that are managed thereby achieving dual control and split knowledge of the key © 2017 ASC X39, Inc. — Alll rights reserved in accordance with Section 7.1.1, 23 ANSI X9.24-1-2017 ii) as two or more key shares that are managed in accordance with Section 7.1.1, thereby achieving dual control and split knowledge of the key iii) as a cleartext key while being injected in accordance with Section 7.9.3 under dual control in an environment meeting the requirements of Section 7.3.3 7.1.3 Logging All instances in which cleartext key components or shares are created, received, accessed, transported, loaded, stored, or destroyed, SHALL be recorded. A policy that defines the length of time such records are maintained SHALL exist and be in use. Consideration SHOULD be given to the possible need for those records for a finite length of time after the key is removed from service. At a minimum, records SHALL reflect the date, time, person(s) involved, activity type (e.g., generation, destruction, shipment), reason for activity, and TEA bag number. Instances where cryptographic keys are created, transported, received, replaced, or destroyed without manual intervention (e.g., dynamic key exchange) SHOULD event occurred. 7.1.4 be logged in such a way as to provide evidence that the Key Strength The weakest algorithm and key size used within the key hierarchy to provide cryptographic protection, determines the strength of the protection. The cryptographic strength of a key SHALL be at least 112 bits as defined in Table 1 of Reference 19. TDEA cryptographic keys SHOULD be triple length, but SHALL be at least double length keys. AES cryptographic keys may be 128, 192, or 256 bits in length. The cryptographic strength of a key SHALL be considered the minimum of the strength of that key and the strength of any cryptographic key that has ever been used to encrypt it. For example, encrypting an AES 128 key with a triple-length TDEA key reduces the AES key’s cryptographic key strength to that of the TDEA key, which is 112 bits (see Table 1 of Reference 19). 7.1.5 Key Locations Cryptographic keys SHALL exist in the fewest number of locations consistent with the operation of the system. 7.1.6 Production Key Usage Keys that are known, or have ever been protected by known keys SHALL NOT be used in production. Any key created or protected in equipment that does not meet Section 7.2 SHALL NOT be used in production. Any keys used in a production system SHALL be handled in accordance with the requirements in this document. 7.1.7 Single Purpose Key Use A key SHALL be used for one purpose only. At a minimum, purposes include: 24 1. A PIN Encryption Key SHALL only be used to protect PINs 2. A Key Encryption Key SHALL only be used to protect keys 3. A Data Encryption Key SHALL only be used to protect data 4. An Authentication Key SHALL only be used for authentication © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 5. 7.2 A Derivation Key SHALL only be used for deriving keys Secure Cryptographic Device (SCD) A device used for key management SHALL be a Secure Cryptographic Device (SCD) that meets the Tamper Resistant and/or Tamper Responsive requirements in Part 1 of Reference 3, and have the applicable characteristics (based upon the SCD functionality) in Part 2 of Reference 3. The SCD SHALL NOT rely exclusively on Tamper Evident characteristics, regardless of the key management method employed. For any SCD that is not being used as a transaction-originating device, Part 2 of Reference 3 SHALL be used to demonstrate the applicable functionality of the SCD. An SCD that meets the Tamper Resistant requirements in Reference 3, but does not meet the Tamper Responsive requirements therein, SHALL only be used in cases where the compromise of that SCD would not compromise keys or secrets not held within the SCD. Examples include, but are not limited to: 1. Smart cards used for component or share transport or storage 2. Smart cards containing public/private key pair(s) used to facilitate management of HSMs 3. SCDs used to authorize or enable key management functions If multiple cleartext components or shares sufficient to form a key are stored or transported within a single SCD, it is equivalent to having a clear key in the SCD, therefore, the SCD SHALL meet Tamper Responsive requirements in Part 1 of Reference 3. The SCD SHALL enforce management of the components or shares in such a way as to ensure Split Knowledge of the key in accordance with Section 7.1.1. When an SCD is used to generate a key or key component, the SCD SHALL use a random or pseudo-random process such that certain values are not statistically more probable than others from the set of all possible values, in accordance with Reference 2. When a key is entered as components, the SCD SHALL combine all the components using an XOR operation. Figure 1 is an example of the XOR process used to combine key components. Component 1 | A1C0591635DAE058261DF798E28EECEO| ~ Component a 2 f OSS0314DASBOFES02524E7ECE0C845B0 | ‘ XOR \ } \ A850685B906A16C80F3910740246A950 / ( Component 3 | i \ C252FAA13155B4D858AB3A3D7D5933A6A| Key 6AC292FAA1315B4D858AB3A3D7D5933A © 2017 ASC X39, Inc. — All rights reserved 25 ANSI X9.24-1-2017 Figure 1 — Example of XOR Function to Combine Key Components When an SCD is used to fragment a key into shares, the SCD SHALL use an n of m secret-sharing scheme. example of this would be Shamir Secret Sharing. An The management and control of an SCD SHALL comply with all parts of Reference 3. Furthermore, if an SCD does not have a Tamper Responsive mechanism, or if that mechanism is not enabled, the SCD SHALL be stored in an environment that meets at least the criteria of a Minimally Controlled Environment as identified in Section 7.3.1, with additional controls providing reasonable assurance that any unauthorized access to the SCD can be detected. Because the SCD cannot respond to an attack, the additional controls minimize the probability of unauthorized modifications. An SCD is decommissioned when it is removed from service for repair, ownership is transferred to another organization, or the SCD is to be destroyed. When an SCD is decommissioned, the financial keys SHALL be erased in accordance with Part 1 of Reference 3. from service as practical. The keys SHOULD be erased as close to the time of removal When an SCD is lost or stolen, all keys contained in that device SHOULD 7.3. 7.3.1 Environments Minimally Controlled Environment A Minimally Controlled Environment is an environment that has been Reference 3, and all answers to applicable items are TRUE. 7.3.2. measured using Part 2, Annex H.3 of Controlled Environment A Controlled Environment is an environment that has been measured and all answers to applicable items are TRUE. 7.3.3 be considered compromised. using Part 2, Annex H.4 of Reference 3, Secure Environment A Secure Environment is an environment that has been measured using Part 2, Annex H.5 Reference 3, and all answers to applicable items are TRUE. 7.4 7.4.1. Key Blocks Overview of key blocks An encrypted key is carried in a structure called a key block. along with other data associated with it. The key block contains the encrypted key itself The key block is protected so that secret data cannot be disclosed (encryption) and so that neither the encrypted key nor the associated data can be modified without detection (integrity). Figure 2 is a high-level illustration of the structure a key block may have but is not intended to be prescriptive. Non-Sensitive Key Attributes <Not <a 26 Encrypted Key and Sensitive Attributes ml~< Integrity Protected Encrypted—4#\4@_ > © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 Figure 2 — Key Block Overview Example The key and its sensitive attributes SHALL be encrypted. If the secrecy of the attribute is important to security of the key and key block, it SHALL be considered a sensitive attribute. The encrypted key and its attributes in the key block SHALL have integrity protection such that they cannot be modified without detection. Modification includes, but is not limited to: 1. changing or replacing any bit(s) in the attributes or encrypted key 2. interchanging any bits of the protected key block with bits from another part of the block The key block SHALL contain the entire encrypted key (or component or share) and any attributes that are required according to this standard. In addition, either the encrypted or the unencrypted portion of the key block may have additional data that is outside the scope of this standard. ANS TR-31 7.4.2 is an example of a key block that meets the requirements in Section 7.4. Key attributes The key attributes are values associated with the key that define how the key can be used and other pertinent information. Ata minimum, the attributes SHALL include the following: 1. One or more attributes that define the operations for which the key can be used. Examples of attributes that define permitted operations include ones that specify that the key can be used only for PIN block encryption, only for encrypting other keys, or only for computing message authentication codes (MACs). Other attributes might define sub-categories, for example specifying whether a MAC key can be used to generate a MAC, to verify a MAC, or both. 2. One or more attributes that define the cryptographic algorithm and mode for which the key can be used. These attributes are intended to prevent the misuse of a key using a mode that could facilitate an attack to determine the value of the key. different cryptographic algorithm or Security requirements for key attributes are specified in Section 7.4.1. 7.4.3 Integrity of the key block Acceptable methods of implementing the integrity requirements specified in 7.4.1 include, but are not limited to: 1. a MAC computed over the concatenation of the cleartext attributes and the enciphered portion of the key block, which includes the encrypted key itself 2. an asymmetric digital signature computed over the concatenation of the cleartext attributes and the enciphered portion of the key block, which includes the encrypted key itself 3. an integrity check that is an implicit part of the key encryption process such as that which is used in the AES Key Wrap process specified in Reference 17 Before the key in the key block is used, the SCD that will use it SHALL verify the integrity of the key block using the appropriate method for the integrity check process that was used on that block. The key SHALL NOT be used if the integrity check fails. © 2017 ASC X39, Inc. — Alll rights reserved 27 ANSI X9.24-1-2017 7.4.4 Key and Sensitive Attributes Field 7.4.4.1 Content of the field At a minimum, the Key and Sensitive Attributes field of the key block SHALL contain the value of the key, but may also contain other data. For example: 1. Padding that has been used to extend the length of the cleartext key to some desired length before it is encrypted. One purpose of this is to pad a key to the block size of the algorithm used to encrypt it. Another purpose is to hide the true length of the cleartext key, for example by padding so that all keys have the same encrypted length 2. Information indicating the length and location of the key to assist in parsing 3. Any sensitive attributes of that key that need to be kept secret 7.4.4.2. Wrapping of the Key and Sensitive Attributes Field Electronic Code Book mode SHALL NOT be used to encrypt this field if the field is longer than one block. The Key and Sensitive Attributes Field SHALL be wrapped with TDEA or AES in accordance with Reference 17 or using one or more of the following modes: 7.5 7.5.1 e Cipher Block Chaining (CBC) (see Reference 6) e Counter with CBC-MAC (CCM) (see Reference 7) e Galois/Counter Mode (GCM) (see Reference 8) Key Creation Random Key Generation Keys SHALL be generated by using a random or pseudo-random process such that certain keys are not statistically more probable than others from the set of all possible keys. The strength of the random number generator SHALL be equal to or greater than the strength of the key it is generating. See Reference 2. Keys SHALL be generated within an SCD. 7.5.2 Key Derivation Key derivation is a technique by which a (potentially large) number of keys are created (“derived”) from a single key and non-secret variable data. The original single key is called a “derivation key” and each key generated from it is called a “derived key”. Key derivation can be used with a variety of key management methods and algorithms. It SHALL be cryptographically infeasible to recover the derivation key from the derived key. For example, DUKPT key derivation can be used to provide a (statistically) unique key for each cryptographic device without the need to manage a large number of separate, unrelated keys. This eliminates the need to store the cipher text of each initial DUKPT key at the acquirer or receiving node. 28 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 7.5.3 Key Calculation (Variants) Applying a variant is a reversible technique for obtaining a set of keys from a single key, with each resulting key having a different key type. This technique provides separate, unrelated key of each required type. key separation while eliminating the need to manage a Each variant key is calculated from the original key and one constant from a set of non-secret constants using a reversible process. An example of such a process is the modulo-2 addition (i.e., XOR) of the key and a non-secret value. The disclosure of one key calculated in this manner discloses the original key and all other keys calculated from it. A variant of a key SHALL be used only for key separation based on usage. Except for TDEA variants is deprecated, thus SHOULD NOT be used. AES keys SHALL NOT use variants. If a key is compromised, then all variants of the key are also compromised. DUKPT, use of If there are multiple variants of a key, and any one of those variant keys is compromised, then all variants and the original key are also compromised. 7.6 Key Component and Key Share Creation Cleartext keys maintained outside of an SCD SHALL be managed under the principles of split knowledge and dual control. In support of this, the key can exist as multiple components or shares. Components can be generated individually and combined to form a key, or created from an existing key. The process to manage a key as shares requires the generation of the key and then fragmentation into shares. Creating components or shares of a key can be done at the time of key generation or at a later date. Key components SHALL be generated by using a random or pseudo-random process such that certain values are not statistically more probable than others from the set of all possible values. See Reference 2. Key shares and components SHALL be generated within an SCD. The creation of components or shares of a key after generation SHALL occur within an SCD. If component generation or fragmentation into shares produces clear, human readable values, the process SHALL occur in Controlled Environment or a Secure Environment as defined in Section 7.3. During the generation process, cleartext components SHALL only be displayed or printed on a device that meets the criteria of an SCD. Cleartext components produced during generation displayed on the SCD may be recorded on paper by the assigned key custodian. 7.7 Check Values 7.7.1 Introduction A Check Value (CV) can be instrumental in validating that a key existing in two places is the same key without disclosing the key itself. For example, an organization receiving a key from another organization may wish to have a method to confirm that the components received have been loaded correctly. different keys may have the same CV. CVs generated on keys are called Key Check Values (KCVs). Component Check Values (CCVs). Within a large set of keys, CVs generated on key components are called If a KCV is used to verify keys and the calculated KCV does not match the expected KCV, the key SHALL NOT be used until an investigation is performed to determine the cause of the mismatch. © 2017 ASC X39, Inc. — Alll rights reserved 29 ANSI X9.24-1-2017 7.7.2. Check Value Calculation A Check Value SHOULD be calculated with a key or component at the time of generation. When a check value is calculated for a key or key component, it SHALL be calculated by a cryptographic process such that all portions of the key or key component are involved in calculating the check value. It is a significant security risk to calculate check values on portions of the key individually (for example, a separate check value for the right and left halves of a double length TDEA key). Thus, in the description of this algorithm, the term “Key” always refers to the entire key (for example, all 112 bits of a double-length TDEA key and all 192 bits of a triple-length TDEA key). If calculating CVs for TDEA keys, Section A.2 or 0 of this standard SHALL be used. If calculating CVs for AES keys, Section 0 of this standard SHALL be used. When displaying or recording the component check value or key check value computed according to Section A.2, no more than the six hexadecimal digits of the cipher text SHALL be used. When displaying or recording the component check value or key check value computed according to Section 0, no more than the ten hexadecimal digits of the cipher text SHOULD be used. 7.8 7.8.1 Key Distribution Introduction Cleartext keys are distributed as components or shares of the key, or by using an SCD to transport the entire cleartext key. Keys, components, and shares encrypted in accordance with Section 7.1.2 of this standard can be transmitted through unprotected communication channels. Regardless of key distribution method used, it SHALL NOT be possible for any person to ascertain the final key during the distribution process. In some cases, it is expedient to have authorized individuals carry (i.e., convey) components or shares of the key from one place to another (e.g., from the point of storage to the point of loading). Requirements for this type of situation are covered in Section 7.8.2 on Personal Conveyance. The sections covering Transporting Components or Shares (Sections 7.8.3 and 7.8.4) describe the requirements that apply when the transportation of the component(s) or share(s) is not under the physical control of authorized persons at all times (e.g., when mailing). 7.8.2 Personal Conveyance of Cleartext Components or Shares When conveying keys, each cleartext component or share not in an SCD SHALL be in the physical control of only the authorized Custodian and SHOULD be in the possession of the authorized Custodian only for the minimum practical time required to transport the component or share, enter it into an SCD (if applicable), and either securely store or destroy it. The authorized custodian physically carrying a component or share in printed form SHALL ensure that the component or share value is not visible to any unauthorized individual during conveyance. 7.8.3 7.8.3.1. Transporting Cleartext Components or Shares Transporting Cleartext Components or Shares in an SCD Cleartext key components or shares can be transported in one or more SCDs. Transporting multiple components or shares of a given key within a single SCD SHALL be considered equal to transporting a cleartext key within the SCD, and is covered in Section 7.2. This section covers the transport of a single component or share of one or more keys using an SCD (e.g., a single SCD containing “Custodian 1” components for one or more keys). 30 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 The management of a component or share (including the SCD in which the component or share resides) SHALL ensure dual control and split knowledge of the resulting key. For cleartext components or shares transported within an SCD, that SCD SHALL meet the following requirements in addition to those in Section 7.2: 1. Have logical controls to limit access to authorized individual(s) 2. Have logical controls that include protections against attacks (e.g., repeated failed login attempts) 3. Support authentication controls that render the device or user account unusable and/or remove keys when the number of invalid authentication attempts exceeds a pre-defined limit the The process to transport the SCD SHALL comply with Annex B. 7.8.3.2 Transporting Cleartext Components or Shares in Printed Form or on Transport Media Transport Media refers to any device that is used to contain a component or share that does not meet the criteria of an SCD (as defined in Section 7.2). The sender and receiver have equal responsibility for the secrecy of the cleartext components or shares that are transported in printed form or on transport media. Both parties SHALL have procedures to ensure the secure handling of the components or shares throughout the process in accordance with the principles of Dual Control and Split Knowledge as described in Section 7.1.1. The process to transport key components SHALL be in compliance with Annex B. 7.8.4 or shares that are in printed form or contained in Transport Media Transporting Cleartext Keys Using a Portable Key Loading Device Cleartext keys can be distributed using an SCD as a Portable Key Loading Device (PKLD) intended to be used for injection outside the KIF. This section addresses the loading of entire keys into the PKLD; the loading of key components and shares into the PKLD is addressed in Section 7.9.2. The PKLD is prepared within a Key Injection Facility (KIF) and one or more cleartext keys (and associated key identifiers, if required) are transferred into the PKLD from another SCD. The PKLD is then physically transported to one or more other SCDs (e.g., for injecting transaction-originating SCDs). The loading and operation of the PKLD is performed under dual control. This differs from the preceding cases where the key is under dual control because the key components or shares are under dual control. Requirements related to the use of the KLD to install the keys into target SCDs are covered in Section 7.9.3. When PKLDs are used to transfer cleartext keys to other SCDs, the PKLD SHALL be prepared (including key loading and any sensitive user configurable settings) within a KIF that meets the criteria of a Secure Environment as described in Section 7.3. User credentials with access to change configurable settings (e.g., inactivity timeout) on the PKLD system SHALL NOT be used to inject keys in the field. The cleartext keys being loaded into the PKLD SHALL encrypted keys into a PKLD need not occur at the KIF. destination SCD is covered in Section 7.9.3. be loaded in compliance with Section 7.9. Transfer of Use of the PKLD to load the cleartext keys into the In the case of a known or suspected compromise of a PKLD (including one that is lost or stolen), all keys that reside in the device SHALL be considered compromised and the response SHALL be in accordance with Section 7.15. © 2017 ASC Xg, Inc. — Alll rights reserved 31 ANSI X9.24-1-2017 Each key loaded to the PKLD SHALL be assigned a lifespan for existence within that PKLD. When setting the lifespan for each key consideration SHOULD be given to the risk of compromise to other keys not installed in the device, if the PKLD were lost. For example, if the PKLD is loaded with a BDK, the loss of the PKLD would impact every device that was injected with a key derived from that BDK, therefore, the lifespan may be shorter. If the PKLD only contained the Initial DUKPT Keys to be injected, the risk is only to those Initial DUKPT keys; therefore the lifespan of those keys may be longer. The PKLD used to transport cleartext keys SHALL meet the following requirements: 1. Have Tamper Responsive characteristics as defined in Part 1 of Reference 3, using Part 2 of Reference 3 to evaluate the applicable functionality of the SCD 2. Have controls to: a) — Limit access to the PKLD to authorized individual(s) by i) separating the administration, key custodian, and operator (injection) functions ii) requiring at least 2 users authorized for the same function to authenticate to the PKLD before the function is available b) c) | Support the authentication controls that render the device or user account unusable and/or remove the keys when the number of invalid authentication attempts exceeds a pre-defined limit Log user activities d) — Protect against unauthorized modification of internal logs 3. Be designed and configured to: a) Minimize the possibility of intercepting the cleartext key using radiated electromagnetic signals (e.g., using a shielded cable) b) Prohibit the cleartext display of entered passwords c) Erase each key that remains inside the PKLD longer than its defined lifespan d) — Limit the total number of injections that can be performed before the PKLD is reloaded e) Provide a means for the operators to confirm the number of injections performed since the PKLD was prepared f) g) h Disable any unnecessary functionality during key injection | Have amechanism to log SCD identifiers (e.g., serial number) injected Confirm to the operator that the key was loaded successfully Delete the emitted cleartext key from the PKLD after injection into the target SCD(s) The process to transport keys using a PKLD SHALL be in compliance with Annex B. When not in use and not housed within a KIF, a method is used to store the PKLD that ensures that unauthorized access attempts would be detected before its use (e.g., storage within tamper evident and authenticable packaging, locked in a dual control container, or showing unauthorized access attempt count). Documented chain of custody SHALL extend from the time of departure from a KIF until it is securely returned including any shipment. Management of the PKLD SHALL unauthorized PKLD access or use is detected. 32 include the review of log information to ensure that © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 7.9 Key Loading 7.9.1 General Key Loading as described in this section includes loading of key components or shares, and loading of cleartext keys (it does not include the loading of encrypted keys). Key loading can be done with the full key being passed between directly connected SCDs, or as components or shares loaded individually to the SCD. This section covers the specific requirements related to each method. Regardless of key loading method used, it SHALL be infeasible for any person to ascertain all or part of any final key during the key loading process. To facilitate the detection of errors in key loading, the check value for key components and keys SHOULD verified. be Key loading activity SHALL be recorded in an automated and/or manual log that contains: 7.9.2 1. An identifier specific to the physical device of any hardware involved (e.g., Serial Number) 2. The Custodian(s) involved 3. A key identifier (e.g., a key name, KCV, BDK ID) 4. The key type 5. The component(s), or share(s) loaded, if applicable (e.g., Component 1, Share B, Check Value) 6. The date and time of the activity Loading Key Components or Shares The integrity and authenticity of the physical mechanism protecting a cleartext key component or share SHALL be verified prior to installation into the target SCD. Physical mechanisms include but are not limited to: 1. TEA bags 2. Transport SCD During loading, each cleartext component not in an SCD SHALL be in the physical possession of only the authorized Custodian and SHOULD be in the hands of the authorized Custodian only for the minimum practical time required to transport the component or share, enter it into an SCD (if applicable), and either securely store or destroy it. The authorized custodian physically carrying a cleartext component or share in printed form SHALL ensure that the component or share value is not visible to any unauthorized individual during conveyance and entry. A key component or share SHALL be entered into a target SCD using one of the following methods: 1. Entered directly into an input mechanism that is integral to (i.e., within the SCD) the target SCD in such a way as to protect against monitoring (e.g., using the EPP of ATM) 2. Inencrypted form as outlined in Section 7.1.2 3. Entered from a directly connected portable source SCD (i.e., a KLD or other SCD) that was used to transport the components of the key to be loaded into the target SCD as described in Section 7.8.3.1 © 2017 ASC X9, Inc. — All rights reserved 33 ANSI X9.24-1-2017 Once a cleartext component or share has been loaded, it SHALL either be destroyed immediately or transported securely for subsequent storage or destruction. Transportation of component(s) or shares(s) SHALL be in compliance with Section 7.13.3. Whether destruction of key component(s) or share(s) is done immediately or subsequent to secure transport, it SHALL be in compliance with Section 7.13. 7.9.3 Cleartext Key Loading 7.9.3.1 General A cleartext key SHALL only be transferred (i.e., injected) directly from one (source) SCD to another physically connected (target) SCD. The source is a Key Loading Device, which is an SCD with specific injection functions. The authentication by at least two KLD operators SHALL the target SCD. be required to enable the KLD to transfer the key into Users that authenticate to the KLD during key injection SHALL only have access to the functionality necessary for key injection. Password entry SHALL be protected against monitoring. The transfer of a key from the KLD to the SCD SHALL only occur after confirmation that the SCD is legitimate and has not been subject to unauthorized target SCD as legitimate prior to injection. modification. The KLD SHOULD have a mechanism to confirm the Keys SHALL NOT be retained within the KLD after they are emitted to the intended SCD(s). A Base Derivation Key SHALL NOT exist in any transaction-originating SCD at any time. If multiple instances of a BDK are loaded to one (or more) KLD, there SHALL be a method employed that ensures each Initial DUKPT Key (IDK) derived from each instance of the BDK and KSI is unique. Methods could include, but are not limited to: 1. Use unique BDK IDs 2. Use of device serial numbers in place of an incrementing Derivation ID 3. An assignment of a range of Derivation IDs for each KLD on which the BDK is loaded 7.9.3.2. KLD Use in a Key Injection Facility A Key Injection Facility (KIF) SHALL be an area that qualifies as a Secure Environment as described in Section 7.3.3. The process to use a KLD to inject keys inside a KIF SHALL include: 1. Prior to use, an inspection to ensure that the KLD, cables to be used, and target SCD, show no signs of tampering 34 2. Dual control is maintained by at least two authorized injection operators from the time of inspection to completion of the key transfer activities 3. Ensuring that the input of user authentication information is not monitored 4. Confirmation prior to injection, that the target SCD is legitimate and the intended device © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 5. 6. Electronic and/or manual logs depicting the date, time, operator(s), target SCD identifier (e.g., SCD Serial Number) and injection outcome for use of the KLD Provide reasonable assurance that the integrity of the logs has been maintained (e.g., electronic logs that are secured by the system against manipulation or manual logs stored in the dual-control KIF) Key injection organizations SHALL authorized injection requests. 7.9.3.3 have a mechanism or procedure in place to reconcile actual key injections to KLD Use Outside a Key Injection Facility Loading keys and other security-related preparation of a KLD SHALL take place inside a KIF (see Section 7.8.4). The process to use a KLD to inject cleartext keys outside a KIF SHALL include: 1. Validation that the KLD has not been substituted. Such validation SHALL be performed by an authorized person other than the one transporting the KLD using an identifier or authentication mechanism that cannot be altered after the KLD has been prepared within the KIF 2. Prior to use, an inspection to ensure that the KLD, cables to be used, and target SCD, show no signs of tampering 3. Dual control is maintained by at least two authorized injection operators from the time of inspection to completion of the key transfer activities 4. Ensuring that the input of operator authentication information is not monitored 5. Confirmation prior to injection, that the target SCD is legitimate and the intended device 6. Electronic and/or manual logs depicting the date, time, operator(s), target SCD identifier (e.g., SCD Serial Number), sufficient attribute(s) to uniquely identify the key used (e.g., a key name, BDK ID, KCV) and injection outcome for use of the KLD 7. Protection of the logs to ensure their integrity 8. Reconciliation of the logs reflecting the use of the KLD to ensure only authorized injections occurred while outside the KIF The KLD SHOULD have a mechanism to confirm the target SCD as legitimate prior to injection. 7.10 Key Utilization A host is a single organization that may include multiple locations, systems, and devices. Any key used by a communicating pair (e.g., host to host or PED to host) SHALL be unique (other than by chance). While a communicating pair could be a transaction-originating terminal and its host, this requirement is not meant to imply that a base derivation key has to be unique to a PED or a single merchant. A key SHALL be used for one purpose only, for example the encryption of data or the protection of a PIN. However, with TDEA keys, a variant of a key may be used for a purpose different from that of the original key (e.g., to differentiate between key types). Controls SHALL be provided to prevent key misuse. A variant of a key SHALL exist only in a device that possesses or has possessed the original key. © 2017 ASC Xg, Inc. — Alll rights reserved 35 ANSI X9.24-1-2017 A key shared between two hosts SHALL be unique to that relationship, ensuring that compromise of a key shared with one host does not impact the security of the relationship with any other host. Any key resident in a transaction-originating SCD SHALL exist only in that device and those facilities that are authorized to have the key. If the transaction-originating SCD has multiple cryptographic relationships, there SHALL be unique keys for each cryptographic relationship. For example, a PED that communicates with Acquirer 1 and Acquirer 2 would have different keys for each Acquirer. In the case where a PED communicates with an Acquirer with multiple locations, the same key can be used at each location. Entities using DUKPT or other key management strategies using derivation methods SHOULD incorporate a segmentation strategy (e.g., by financial institution, injection vendor, market segment, processing platform, sales unit, etc.) in their environments to limit the impact of a compromise. The SCD SHALL have a means to ensure the separation of keys according to cryptographic function. Except for TDEA DUKPT, use of variants is deprecated, thus SHOULD NOT be used. AES keys SHALL NOT use variants. Except for AES replacement. DUKPT as specified in Reference 9, a key SHALL NOT be used to encrypt itself or its 7.11 Cleartext Key Component and Share Storage The storage of cleartext components and shares SHALL be sufficient to ensure that only the authorized custodians similarly entrusted with that component or share can obtain access to the component or share. Components and shares SHALL be stored in sealed TEA bags. Each component or SHALL be stored in a separate TEA bag. Components or shares of different keys separate TEA bags. When multiple components or shares of different keys are stored without being in separate TEA bags within, and that TEA bag is opened, logs SHALL component or share that was contained in the TEA bag. share of the same key SHOULD be stored in in the same TEA bag record access to each The chain of custody of a key component or share SHALL be maintained for the life of the key. Each time a TEA bag is placed into or removed from storage, there SHALL tampering and validation that the TEA bag identifier is as expected. 7.12 be an inspection for evidence of Key Replacement A key rotation policy SHALL exist that defines the cryptoperiod for keys owned by the organization. At or before the conclusion of the key’s cryptoperiod, it SHALL be replaced. Considerations for the rotation schedule may include (but are not limited to): 36 1. keyuse 2. key type 3. key strength 4. amount of sensitive data being encrypted 5. key management history 6. key management method (See Section 8.1) © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 A key SHOULD be retired if it has been managed component has not been maintained. as components or shares, and clear history of a single An unauthorized attempt to enter a key or restore a replaced key (e.g., replay) SHALL be precluded or detected. 7.13 Key Destruction 7.13.1 General Keys are destroyed when they are no longer operationally necessary. locations and at multiple organizations. key. Keys can exist in multiple forms in multiple The process of destroying a key SHALL involve all known forms of the 7.13.2 Key Destruction from an SCD The method of destruction for keys inside an SCD SHALL be sufficient to ensure that it is infeasible to recover the keys by physical or electronic means. All manually initiated destruction activities, including the purposeful initiation of a Tamper state SHALL be logged, with appropriate records retained for audit trail purposes. 7.13.3 Destruction of a Key in Cryptogram Form In order to destroy the cryptogram form of a key, the destruction process SHALL include one or more of the following: 1. removing the key cryptogram(s) from the operational environment(s) 2. destroying all forms of the key used to create the cryptogram Operational processes SHALL ensure that destroyed keys are not reintroduced. 7.13.4 Component and Share Destruction Components or shares stored on non-paper media SHALL be destroyed so that it is infeasible to recover the component or share by physical or electronic means. The destruction SHALL be completed by the authorized component holder, and be witnessed by another authorized individual. Paper-based components destruction SHALL individual. or shares SHALL be destroyed by crosscut shredding, burning or pulping. The be completed by the authorized component holder and be witnessed by another authorized 7.14 Key Archiving An archived key is an inactive key that is being saved in a secure manner for a non-operational purpose. Legal or regulatory requirements and forensic investigations are examples of instances that could require recovery of an archived key. Archived keys SHALL be managed in accordance with this standard. Archived keys SHALL NOT be restored into the operational environment. © 2017 ASC Xg, Inc. — Alll rights reserved 37 ANSI X9.24-1-2017 7.15 Key Compromise In the situation where a key’s integrity is in question, an investigation SHALL be initiated to identify the possibility of exposure. A suspected compromise is when the management of a key or its components would present the opportunity for exposure or unauthorized use. Examples of situations where a key’s integrity may be in question include (but are not limited to): 1. An SCD showing signs of or displaying an alert that indicates possible tampering 2. Inconsistent key activity logging 3. Components not stored in TEA bags 4. TEA bag records inconsistently maintained, or gaps in the TEA bag history for any one component of the key If components or shares of a key are compromised, as defined in Section 4.19, and the result is that one person could have knowledge of the key, the entire key SHALL be considered compromised, and its use discontinued. For example, if the key exists as two components, and a single component is no longer secure, and the legitimate custodian of the remaining component were to discover the lost component, he would then have had access to the entire key. If the key exists as more than two components or shares, and a single component or share is lost, then the key is not necessarily considered compromised. In a situation where a single person is not able to gain knowledge of the entire key, but one or more components or shares of a key has been lost, compromised, or suspected compromised, the entire key SHOULD be replaced. The use of a key SHALL be discontinued if its compromise is known or suspected. The amount of time for which the compromised key remains active SHOULD be consistent with the risk to affected parties. The use of a key protected by a compromised key SHALL be discontinued. If the compromised key is a derivation key, then use of any key derived from that key SHALL be discontinued. Key destruction SHALL be in accordance with Section 7.13. In the case of a compromised key, a new key SHALL be generated or derived in accordance with Section 7.5 or Section 7.5.2. If the new replacement key. key is derived, no compromised key SHALL be used in the process to create the The notification of a key compromise SHALL be communicated to all parties that may be relying on the secrecy of the compromised key. 38 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 8 Transaction Key Management Techniques 8.1 General This section specifies the methods of transaction key management . Key management methods used singularly or in combination SHALL be restricted to the following: 8.2 e Fixed Transaction Keys e Master Keys / Transaction Keys e Derived Unique Key Per Transaction (DUKPT) as described in Reference 9 Method: Fixed Transaction Keys For this method, the fixed transaction key SHALL be either physically loaded (see Section 7.9) or remotely loaded as per Reference 4. The fixed transaction key is used for transaction processing until a new key is similarly loaded. 8.3 Method: Master Keys / Transaction Keys In this method, there is a Master Key used to protect other keys during distribution. The Master Key is a Key Encrypting Key (KEK) used for the distribution of new or replacement Key Encrypting Keys, Derivation Keys, and/or Transaction Keys. This method is also known as the Master Key / Session Key method. In a two-layer hierarchy, the Master Key is used to encrypt Transaction Keys directly. Alternatively, multiple levels of Key Encrypting Keys may be used. In that case, the highest-level KEK SHALL be either physically loaded (see Section 7.9) or remotely loaded as per Reference 4. A key SHALL NOT be used to encrypt itself or its replacement (except as permitted in Section 7.10). The effective and minimum strength of an encrypted key (e.g., transaction key) SHALL be determined according to Section 7.1.4. Since the Master Key is a Key Encrypting Key, it SHOULD have cryptographic strength equal to or greater than the keys it encrypts. Within a using a effective strength cryptographic relationship, if one organization is storing or transmitting the key shared between them key that is not of equal or greater strength, that organization SHALL notify the sharing party. The strength of a key shared between two organizations SHALL be equivalent to the lowest effective in either organization. For example, if two organizations share a 128 bit AES key, and one organization encrypts the key under a 112 bit (double-length) TDEA Master File Key and the other organization encrypts the key under an 128 bit AES Master File Key, the strength of the shared key for both organizations is 112 bits, based on application of the logic in Section 7.1.4. © 2017 ASC Xg, Inc. — Alll rights reserved 39 ANSI X9.24-1-2017 Annex A (Normative) Key and Component Check Values A.1_ General A check value is a cryptographic function of the key that is used to verify the correct key or component. The check value is not considered a secret parameter, which places significant security requirements on the check value algorithm and its usage. A.2__ Legacy Approach (deprecated) The previous version of this standard recommended computing the check value by encrypting an all-zero block using the key or component as the encryption key, see Figure 3. When using this method, the check value is the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits). There are a number of known security problems with this approach. First, if the check value consists of the entire ciphertext, then it is possible that the check value can be used to enter a known ciphertext into the system. For example, the check value for a key wrapping key is identical to the ECB key wrap of a single-DEA key with a value of all zeros. Even with a check value of only 4 or 6 digits, revealing the partial encryption of all zeros can cause security problems with some modes of operation, particularly counter mode and CMAC. —p{ DEA Decrypt i » K3 DEA Encrypt a, DEA Encrypt / K2 nal NL K1 : -- 0000...0000 KCV Figure 3 — Legacy Generation of Key Check Value 40 © 2017 ASC Xg, Inc. - Alll rights reserved ANSI X9.24-1-2017 A.3. CMAC-based Check values A.3.1 Algorithm Check values calculated using this approach are calculated by MACing an all-zero block using the CMAC algorithm as specified in Reference 14. The check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). Note that the block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a component of a TDEA key will be MACed using the TDEA cipher, while a 128-bit AES key or component will be MACed using the AES-128 block cipher. block With a fixed input of the all-zero block, the CMAC value is calculated as shown in Figure 4. ae 0000...0000 Key —»> Block Encrypt Yes MSB=1? —> { Ne | <<1 Key © ——~» <<1 <<— XoR <— Rp Block Encrypt | KCV | Figure 4 — CMAC Generation of Key Check Value The values of R, are a bit string determined by the number of bits in the block where b is the block length. R123 = 0'°10000111 which is a 128 bit value for AES-128, AES-192, and AES-256 and Rea = 0°'11011 which is a 64 bit value for TDEA. Table 1 reflects these values in numeric form. These values are static for CMAC when used with all 128 bit block ciphers and 64 bit block ciphers respectively and they are calculated according to the CMAC specification in Reference 14. Note that the definition of 0'”° is the zero bit repeated 120 times and 0° is the zero bit repeated 59 times. © 2017 ASC X39, Inc. — Alll rights reserved 41 ANSI X9.24-1-2017 Table 1 - Complete Hex Values for R, Rp Rizg Block Size _ | Value |: 128 bits Reg 64 bits A.3.2 Examples 0x00000000000000000000000000000087 0x000000000000001B Algorithm | Key Check Value AES-128 1234567890ABCDEFFEDCBA0987654321 3F077B8FAA AES-128 00112233445566778899AABBCCDDEEFF 53E107B36E AES-192 1234567890ABCDEF 1234567890ABCDEF 1234567890ABCDEF 0C1589E01B AES-256 0000111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFF | F665910B72 42 © 2017 ASC X39, Inc. - Alll rights reserved ANSI X9.24-1-2017 Annex B (Normative) Split Knowledge During Transport B.1 General When two or more items must remain separate during transport (when not in the possession of the authorized custodian, which is covered in Section 7.8.2) to support management of a key with split knowledge, it is necessary to implement a process to detect (and prevent where possible), any unauthorized access during the transportation and provide adequate evidence to demonstrate that no exposure occurred. Such items include but are not limited to: 1. components or shares of a key 2. an SCD used to carry keys for intermediate loading to an SCD, and the authentication parameters used to enable or access it 3. an SCD used to carry components or shares, and the authentication parameters used to enable or access it This annex describes the required procedural elements and the evidence to maintain in order demonstrates split knowledge during transport. B.2 Packaging The packaging that protects the item during transit includes all barriers put around the item that are meant to protect it from disclosure. All items not contained within a Tamper Responsive SCD SHALL be sealed within a TEA bag. For written items, 1. It SHALL not be feasible to reveal the secret, even with manipulation of any interior barrier without opening the TEA bag (e.g., unfolding a trifold piece of paper or opening an unsealed envelope that are contained within the TEA bag) 2. The packaging SHALL be sufficient to ensure the value can’t be read through the TEA bag. This could be a combination of a security envelope inside a TEA bag or could depend upon the TEA bag itself. courier mailer is not sufficient to prevent disclosure A For items shipped within electronic media, 1. Packaging SHALL be sufficient to protect items stored within electronic media such that it cannot be read or accessed through the packaging 2. When selecting packaging for electronic media, consideration SHOULD be given to the fact that it is possible to access various forms of media through certain types of packaging material without detection. For example, a magnetic stripe card needs to be protected from being read while remaining inside the TEA bag. B.3 Separate Shipment © 2017 ASC X39, Inc. — Alll rights reserved 43 ANSI X9.24-1-2017 Separation of the items SHALL be achieved by one or more of the following: 1. Different communication channels (in permissible forms) 2. Use of at least two transportation couriers 3. Different dates When choosing the method with which to separate if the key were to be compromised during transit warrant separation by both courier and date. A confirmation of receipt for each shipment before the B.4 item shipment, consideration SHOULD be given to the impact (e.g., a key already protecting production information may Master File Key already protecting other keys may warrant next package is sent). Receipt Confirmation Participation from the sender and receiver is necessary to ensure that the package received is the package that was sent, and that it was received intact. The process SHALL include: 1. Designation of the individuals (not roles) authorized to send and receive items (i.e., “John Smith” not “Component Holder 1”) Use of a transportation channel(s) that allows for tracking (for items being shipped) An inspection by the receiver for signs of tampering Confirmation that the package was not substituted (e.g., matching tracking and TEA bag numbers) If an SCD, verification that it was not substituted using information that was received separate from the package itself (e.g., confirming the device serial number or a cryptographic means to validate the SCD was not substituted) B.5 d) Transport Logging Logs detailing the activities for shipping and receiving SHALL be consistent with Section 7.1.3, and SHALL also include: 1. Items transported 2. Method of transport Evidence that the package the package was not substituted and showed no signs of tamper Evidence indicating the device was not subject to substitution 44 © 2017 ASC XQ, Inc. — All rights reserved

ANSI ASC X9 X9.24-1-2017

Related documents

Products

Support

ANSI ASC X9 X9.24-1-2017

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib