WO2018002792A1 - Electronic system of acquisition for transceiving banking data - Google Patents

Electronic system of acquisition for transceiving banking data Download PDF

Info

Publication number
WO2018002792A1
WO2018002792A1 PCT/IB2017/053762 IB2017053762W WO2018002792A1 WO 2018002792 A1 WO2018002792 A1 WO 2018002792A1 IB 2017053762 W IB2017053762 W IB 2017053762W WO 2018002792 A1 WO2018002792 A1 WO 2018002792A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
terminal
cyphering
kip
des
Prior art date
Application number
PCT/IB2017/053762
Other languages
French (fr)
Inventor
Giorgio DORKIN
Graziella BARTUCCA
Original Assignee
Bancomat S.P.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bancomat S.P.A. filed Critical Bancomat S.P.A.
Publication of WO2018002792A1 publication Critical patent/WO2018002792A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Definitions

  • the present invention relates in general to the field of electronic data exchange systems and in detail it relates to an electronic acquisition system for transceiving banking data.
  • the present invention also relates to an acquisition system for transceiving banking data.
  • the object of the present invention is therefore to describe an electronic system of acquisition for transceiving banking data which allows optimizing the safety of the stakeholders.
  • an electronic system of acquisition for transceiving banking data which operates with a plurality of issuer banks 102 and the associated operative/authorization centers 103 through which said issuer banks 102 manage a plurality of activities of issuing, wherein the issuer banks 102 receive and transmit electronic data with an interbanking network 104,
  • said electronic system 100 comprises acquirer banks 105 through which said interbanking network 104 transmits and receives electronic data B, wherein the activities of said acquirer banks 105 comprise also those which are developed under their own responsibility by application centers 107 that transeeives electronic data with a plurality of terminal managers 106, which operate as an electronic interface towards a plurality of payment terminals 108 that comprise ATM 109 or POS 1 10 susceptible of being used by a user 101 which is the owner of an electronic payment card 200, wherein
  • the architectural scheme of generation of the RSA certificate provides a single trusted entity having the role of Certification Authority.
  • the CA 122 is hierarchically superior to both the manufacturer terminal 120 and to the GT 121 .
  • the various terminals 108 are managed by the terminal manufacturer 120.
  • the procedure requires both the terminal providers and the terminal operators to generate a pair of RSA keys and certify their public key at the CA.
  • the provider in the process of setup of the terminals, will generate a pair of RSA keys for each terminal (EFT-POS) and certify the public key of the terminal with the private key of the provider.
  • the terminal manager 106 via crypto device, manages the following quantities:
  • KMP for Acquirer master key for the protection of the PIN
  • KIP keys initial key for PEN protection for the EFT-POS terminal
  • the payment terminal 108 manages through its security module the following quantities:
  • said payment terminal 108 and the terminal manager 106 will exchange the certificates and encrypt with their own private key a random number generated and sent by the other party.
  • Each subject terminal manager 106 and payment terminal 108;
  • Said mutual authentication process is carried out by both parties and at the end the two parties will have the public key of the subject with whom they are interacting.
  • the terminal manager 106 then sends the necessary keys to the terminal by encrypting them with the public key of the terminal.
  • the terminal manager 106 creates a check digit of the keys to be sent and encrypts them using its own private key.
  • said payment terminal 108 comprises means of generation of a data packet containing said PIN, wherein said means of generation are activated for both EMV contact and contact! ess transactions and in second trace, and wherein said payment terminal 108 uses the Format 0 which i s defined in the ISO 9564 standard and encodes it with TDES encoding.
  • TRSM ID string and provides in output the first portion of the key Kn , i.e. Kip A ; the second DES encoder 502, further receives in input the string KID jj TRSM ID inverted, and provides in output the second portion of key Ki P , i .e. Ki PB , and wherein the key KIP is therefore given by ⁇ ⁇ Ki PA
  • said payment terminal 108 performs a step of generation of a key of session cyphering KCUR , wherein said key of session cyphering KCUR is generated by means of a cyphering TDES, and in detail wherein said payment terminal comprises a couple of DES encoders 601, 602 wherein said key for protecting financial messages KPOS used for cyphering financial messages exchanged between the payment terminal 108 and the terminals manager 106 is realized by means of said couple of encoders DES 601, 602, wherein together with an identification code of the online operation that i s transmitted on a second input of the first decoder 601 of said couple of DES encoders 601 , 602; said first DES decoder 601 generates in output a first portion of the key of cyphering KCU , that is the portion KCURA, and wherein the same Kpos key is further put in input to a second DES encoder 602, which receives an identification code of the online operation
  • an electronic acquisition method for transceiving hanking data is also implemented, with a plurality of issuer banks 102 and the respective operative and authorization centers 103 through which said issuer banks 102 manage a plurality of issuing activities, wherein the issuer banks 102 receive and transmit electronic data with an interbanking network 104, which through acquirer banks transmit and receive electronic data (B), wherein the activities of said acquirer banks 105 also comprise those carried out under their own responsibility by the application centers 107 performing an operation of transceiving electronic data with a plurality of terminal manager 106, which operate as an electronic interface to a plurality of payment terminal s 108 that comprise ATM 109 or POS 1 10 susceptible of being used by a user 101 which is the owner of an electronic payment card 200; on said payment terminal 108, after a preliminary operation of mutual authentication, described hereinafter, between payment terminal 108 and each of the terminal managers 106, there is at least one protection key of service messages KSER not used to perform a financial transaction, wherein said key is managed by
  • the architectural scheme of generation of the RSA certificate provides a single trusted entity having the role of Certification Authority,
  • the CA 122 is hierarchically superior to both the manufacturer terminal 120 and to the GT 121.
  • the various terminals 108 are managed by the terminal manufacturer 120.
  • the procedure requires both the terminal providers and the terminal operators to generate a pair of RSA keys and certify their public key at the CA ,
  • the provider in the process of setup of the terminal s, wil l generate a pair of RSA keys for each terminal (EFT-POS) and certify the public key of the terminal with the private key of the provider.
  • the terminal manager 106 via crypto device, manages the following amounts:
  • KMP for Acquirer master key for the protection of the PIN
  • KIP keys initial key for PIN protection for the EFT-POS terminal
  • the payment terminal 108 manages through its security module the following amounts:
  • Each subject (terminal manager 106 and payment terminal 108):
  • Said mutual authentication process is carried out by both parties and at the end the two parties will have the public key of the subject with whom they are communicating.
  • One aspect of the present method moreover, comprises a step of release, by the payment terminal 108, of an AP amount cyphered by means of a fixed key TDES cyphering algorithm.
  • said payment terminal 108 executes a step of generation of a data packet containing said PIN, wherein said generation step is executed for both EMV contact and contactless transactions and in second trace, and wherein said payment terminal 108 uses the Format 0 which is defined in the ISO 9564 standard and encodes it with TDES encoding.
  • One aspect of the present method moreover, comprises a step of derivation of said initial key KIP from an initial key KMP or master key PI generated in a device of cyphering or crypto device 404 which receives in input said KMP electronically and automatically selected in accordance with an identification index KID and a random number generated by a tampering-resistant device 402.
  • said payment terminal 108 performs a step of generation of a key of session cyphering KCUR , wherein said key of session cyphering KCUR is generated by means of a cyphering TDES, and in detail wherein said payment terminal comprises a couple of DES encoders 601, 602 wherein said key for protecting financial messages K P os used for cyphering financial messages exchanged between the payment terminal 108 and the terminals manager 106 is realized by means of said couple of encoders DES 601, 602, wherein together with an identification code of the online operation that i s transmitted on a second input of the first decoder 601 of said couple of DES encoders 601 , 602; said first DES decoder 601 generates in output a first portion of the key of cyphering KCUR, that is the portion KCURA, and wherein the same K P QS key is further put in input to a second DES encoder 602,
  • FIG. 1 shows the operating scheme in which the system object of the present invention operates
  • FIG. 2 shows an organization scheme of the encryption keys on a terminal EFT-POS
  • FIG. 3 shows a block diagram of the diversification of key K iP ;
  • FIG. 4 shows a block diagram of an encoding of two partial keys by means of RSA encoders
  • FIG. 5 shows a further block diagram of an encoding of two partial keys by means of RSA encoders
  • FIG. 6 shows a hierarchical block diagram between a certification authority, a plurality of POS or ATM terminals operated by a single manufacturer together with a terminal operator manager;
  • FIG. 7 shows a block diagram of initial loading of the keys.
  • system 100 there is a user 101 who uses a BANCOMAT®/PagoBANCOM AT® card 200 to make an electronic payment.
  • the user 101 interacts with an issuer bank 102, which manages a plurality of issuing activities including the authorization ones also made through an operative/authorization center 103; the issuer bank 102 receives and transmits electronic data with an interbanking network 104.
  • the transmission and reception of electronic data exchanged with the issuing system is schematically indicated in figure 1 by arrow A.
  • interbanking network 104 receives and transmits electronic data with an acquirer bank 105; the transceiver of said electronic data is schematically indicated in figure 1 by arrow B.
  • the activities carried out under the responsibility of the acquirer bank 105 also include those carried out under their own responsibility by the application centers 107 that transceive electronic data with a plurality of terminal managers 106, which operate as an electronic interface to the payment terminals 108 which include, as illustrated in figure 1 , ATM 109 or POS 1 10.
  • POS it is meant an electronic device and the respective banking service that allow a creditor to accept and collect directly on their current account, electronic payments by means of electronic money, or by credit, debit and prepaid cards by the debtor customers.
  • the double vertical bar operator jj refers to an operation of sequencing or concatenation of multiple bits.
  • system 100 object of the present invention defines mechanisms for the protection of data exchanged by the terminal EFT-POS 1 10 with the acquirer bank 105, the minimum requirements for the quantities of security, their use and their management and presents a remote loading mode of such quantities on the terminal EFT-POS 1 10 (key management) with the use of mutual authentication, digital certificates and asymmetric keys.
  • system 100 object of the present invention seeks to overcome some security limits in the section between the POS terminal and the terminal manager which are typical of systems operating according to the IS08583 standard.
  • a header has been introduced in the messages which provides a series of information adapted to identify the sender and the recipient of the message and other information necessary to the proper management of the message itself.
  • the protocol defines:
  • AID means the application identifier which identifies the application present on a chip card
  • AIID means Acquirer Identification, and identifies an acquirer of payment cards within the terminal.
  • CA Certification Authority, which is the entity that manages digital certificates.
  • CVM means cardholder verification method and is therefore defined as the verification method of the cardholder
  • DOL means Data Object List and is a list of data in TLV format.
  • DIJ PT means Derived unique Key per Transaction, namely the key derivation method for symmetric algorithms.
  • GT or manager means terminal manager, which represents the front end of the acquisition infrastructure to the terminals EFT-POS 110.
  • the GT can manage the security functions on behalf of one or more acquirers.
  • IFM means interface module, i .e. a smart card reader interface module.
  • KID means Key Identifier, which is the key index.
  • PED Pin Entry Device, which represents the device for entering the PIN.
  • RID means Registered Application Provider Identifier, which in the context of the present specifications uniquely identifies a payment card network.
  • TDES means Triple DES, namely, a mode of use of the DES algorithm with double or triple- length keys.
  • TLV means Tag Length Value, which is the data representation format.
  • TMS Management Terminal System, which represents the remote management sy stem of the terminals provided by the manufacturer.
  • Kip 128-bit initial key for PIN encryption per single terminal
  • the object of the present document is to also describe the security aspects for financial transactions on the terminals EFT-POS 110.
  • the document defines the mechanisms for the protection of data exchanged by the terminal EFT-POS 110 with the acquirer, the minimum requirements for the quantities of security, their use and their management and presents a remote loading mode of such quantities on the terminal EFT- POS (key management) with the use of mutual authentication, digital certificates and asymmetric keys.
  • the terminals EFT-POS 10 can operate in any of the three present operating modes:
  • the types of keys present on the terminal EFT-POS are the following:
  • KS ER Key for the protection of service messages KS ER (key assignment, parameter assignment, totals, etc) not used for financial transactions, independently of the Acquirer and managed by the Terminal Manager.
  • Kpos Key for the protection of financial messages used for the encryption of financial messages exchanged between the terminal and GT, independently of any additional protections provided for at the transport protocol level.
  • each key is referenced by an index that identifies both the GT and the acquirer, using index '0' by convention to indicate messages without encryption.
  • a mechanism is used that is based on the calculation of a CRC as described in the following part of the description and the TDES encryption of all data of the CRS message included.
  • the general requirements that the terminal EFT-POS must comply with for the management of the online PIN are defined in the IS09564 [8] standard, in particular Part 1.
  • the PIN will be included in a package (PIN Block) which will be encrypted according to the rules defined in this chapter, depending on the type of transaction.
  • PIN Block will be sent by the terminal EFT-POS to the GT in the authorization messages.
  • the terminal must use the Format 0 defined in IS09564 [8] to build the package containing the PIN (PIN Block), which will then be encrypted in TDES mode as specified hereinafter.
  • the encrypted AP is sent in field 52 in the authorization request messages.
  • the encryption of the PIN Block must occur with TDES mode with 128-bit keys.
  • DUKPT For the evolution of the keys, reference is made to the DUKPT method, defined in the X9.24 standard that involves the use of an initial key KIP, derived in turn from an initial key KMP (Master Pin key) inserted/generated in the crypto device.
  • KIP initial key
  • KMP Master Pin key
  • the key KMP is identified by an index Key Set Identifier (KID), It is required that each Manager differs the keys KIP for each terminal.
  • KID Key Set Identifier
  • the key K iP comprises a 3 -byte KSI 401 and a TRSM ID 402 which is a random number of the length, preferably but not limited to 4 bytes.
  • a plurality of files of protected keys Ki, K MP , K 3 ,... ,K n 403 derive from the KSI 401 which are under the Local Master Key in the crypto device 404, which comprises a first module TDES 405 and a second module K iP 406,
  • the KMP selected on the basis of Km is transmitted to the TDES 405,
  • the operations of generation of the KMP and the derivation of the KIP must be carried out through a secure cryptographic device as defined in [10].
  • the string consisting of the KID and TRSM ID must be filled to the right with a byte '80' for the TDES encryption operation for the derivation of the ⁇ ⁇ .
  • Figure 4 shows a block diagram of the derivation of key I3 ⁇ 4p.
  • the MP is sent in input to a DEA or DES encoder 501 , which also receives at its input K ID
  • the KMP is sent in input to a second DEA or DES encoder 502, which also receives at its input Ki D jj TRSM ID, hut this time reversed, and outputs the second key K iP , i.e. K IPB .
  • the acquirer also sends the index K iD of the key K M p and the KS N
  • the KSN is 10 bytes long and has the format shown in the following table:
  • the KSN field must be unique per Manager and for each initialization of each terminal.
  • the terminal manager may possibly assign a KIP and KSN pair for each set of acquisition parameters configured, using different KMP for each acquirer (KMP with different ID).
  • KMP KMP with different ID
  • the terminal must select the KIP to be used, based on the key index associated by the Manager with the Acquirer that has been identified for the specific transaction.
  • the Manager identifier will be sent to the terminal in the key assignment step.
  • the field KSN (whose subfield counter is incremented by the PED) is sent in field 53 of the authorization messages.
  • the encrypted PIN-Block is sent in field 52.
  • All encryption keys of the messages must be managed by the GT and by the terminal as required by the ISO 1 1568-1 standard.
  • the GT must assign the message encryption keys. Together with the keys, the GT also sends the respective index, which must be valued in the header of all messages exchanged between POS and GT.
  • the terminal then only for the financial transactions (messages 1 1x6, 12x6, 14x6 and confirmations 8xx6) must select the K P os to be used on the basis of the index associated to the acquirer identified for the specific transaction. This index must be valued by the terminal in the header of the financial message.
  • the terminal will use the service KS ER assigned in the mutual authentication process.
  • the terminal starting from the Kpos (the same mechanism should be used for the diversification of the KS ER ) must derive a session key, Kcur, to encrypt the current message.
  • Figure 5 shows a block diagram of a diversification to obtain the current encryption key Kcur.
  • the key K P os is placed in input to a first encoder DEA or DES 601, together with an identification code of the online operation which is instead transmitted on a second input of the same first decoder.
  • Said first decoder DEA or DES 601 generates at its output a first portion of the encryption key KCUR, i .e. the portion KCU RA -
  • the same key K P QS is also put in input to a second DEA or DES encoder 602, which like the first encoder 601 receives an identification code of the online operation.
  • the second DEA or DES encoder 602 produces at its output a second portion of the encryption key KCU R , i.e. the portion KCU RB -
  • the applicant points out that the value Online operation identifier' (n6 format in 3 bytes) must be aligned to the right and filled with 5 bytes of '00' hex to the left so as to obtain an 8-byte block.
  • the encryption of this block with the KPOs determines the component KQ U A of the new session key that will be used to encrypt the current message.
  • the 8-byte block consisting of the Online operation ID' formatted as described must be reversed through xor operation with an 8-byte 'FF' hex block.
  • the block thus reversed must be encrypted with the KPOS to obtain the KCurB component of the new session key.
  • Kcur : : KcurA i ! KcurB
  • the terminal must encrypt the entire message. Header and Message Type Identifier excluded.
  • the last block must be filled with a '80' hex and a sequence of bytes '00' to have an 8-byte block.
  • the assignment of the keys in the terminal POS 110 must be made after a mutual authentication between terminal 108 and the Manager.
  • the mutual authentication must be carried out by means of a 2-level public key structure (PKI) with a third trusted entity for the management of digital certificates (CA) as shown in figure 6.
  • PKI public key structure
  • CA digital certificates
  • the architectural scheme provided in the present document provides for a single trusted entity having the role of Certification Authority with certificate format defined in the following parts of the present description.
  • the CA 122 is hierarchically superior to both the manufacturer terminal 120 and to the GT 121.
  • the various terminals 108 are managed by the terminal manufacturer 120.
  • the procedure requires both the terminal providers and the GT to generate a pair of RSA keys and certify their public key at the CA.
  • the terminal provider in the process of setup of the terminals, will generate a pair of RSA keys for each terminal (EFT-POS) and certify the public key of the terminal with the private key of the provider.
  • KMP for Acquirer master key for the protection of the PIN
  • KIP keys initial key for PIN protection for the EFT-POS terminal
  • the terminal provider must manage through its crypto device:
  • the terminal must manage through its security module the following quantities;
  • the terminal and the terminal manager must exchange the certificates and encrypt with their own private key a random number generated and sent by the other party.
  • the manager at this point can send the necessary keys to the terminal by encrypting them with the public key of the terminal (PED).
  • PED public key of the terminal
  • the crypto device 404 exchanges data with acquirer 130 which in turn transmits to CA 122 the public component of the RSA key of the GT PQ and receives from the CA 122 the digital certificate C G together with the public component of the RSA key of the CA 122.
  • the CA122 communicates with a further crypto device 404.
  • the CA 122 transmits the digital certificate of the terminal manufacturer C F and the public component of the RSA key of the CA 122 PCA to Provider 135 and receives from the latter the public component of the RSA key of the terminal manufacturer P F .
  • Provider 135 transmits and receives electronic data in turn with a further crypto device 404.
  • Provider 135 also communicates with a terminal EFT-POS 108 by transmitting and receiving, respectively, to and from the latter, the digital certificate of terminal EFT-POS 108 C T generated by the manufacturer, the digital certificate of the manufacturer CF and the public component of the RSA key PCA of the CA 122, and receives the public component of the RSA key of the single terminal Pr.
  • the pair of RSA keys of the GT must be generated via crypto device.
  • the principle of dual control must still be respected in the performance of key management activities and no unauthorized person can gain access to specific amounts of security.
  • the secret key must be protected by a crypto device and should never be clear outside of the device.
  • the public key of the CA of the Consorzio BANCOMAT® and/or the relative amount of control will have to be stored in special archives protected with a key in turn produced/protected by cryptographic device.
  • the certificate management system must be such as to ensure the division of the same for the specific purpose for which they are intended.
  • the operations of key management also include recording the destruction procedures of security amounts become obsolete and of key compromise situation management.
  • the CA will notify the Managers about the revocations of their keys and the Providers key certificates.
  • the provider must, for each terminal, generate a pair of keys RSA with a minimum length of 2048 bits.
  • the generation of these keys must be made from the security module of the terminal must provide for the export of the public key of the terminal and the acquisition of the terminal certificate, the Provider's certificate and the public key of the CA of the Consorzio BANCOMAT®, Alternatively, the provider may generate the pair of keys RSA of the terminal through its own crypto device and then load these amounts together with the certificates in the terminal security module. Such operations must he carried out with the same security criteria illustrated for the generation of the pairs of keys of the Manager and the Provider.
  • Provider 135 must generate the terminal certificate through the use of a crypto device and its own secret key.
  • Provider 135 should use its own pair of keys and the respective certificate of the public key to initialize up to 5000 terminals and in any case not use it for a period exceeding one year.
  • the structure of the certificates used is that defined in the ISO 9796-2 standard and is the same used in the EMV standard for the offline authentication of the cards and for the interbanking key exchange.
  • the Certification Authority of the Consorzio BANCOMAT® should create a hash with algorithm SHA-1 FIPS 180-1 (ISO 101 18-3) of data shown in the following table, where NCA indicates the length of the public key module of the Certification Authority and NI the length of the public key module of the applicant.
  • Subject 4 Manager Company Code (company code format aligned to the left identification and filled to the right wi th hex FFF) or Terminal Supplier identifier
  • Mash Algorithm 1 Identifies the hash algorithm used to produce the Hash Result in indicator the digital signature scheme: Hex. Field Length Description
  • Subject Public Key I Identifies the digital signature algorithm to be used with the Subject
  • Subject Public Key Identities the length of the Subject Public Key Modulus in bytes Length
  • Subject Public Key- I Identifies the length of the Subject Public Key Exponent in bytes Exponent Length
  • Subject Public Key- 1 or 3 Subject Public Key Exponent equal to 3, or 2 16 + 1
  • CA 122 encrypts with its own private key SCA the following amount:
  • Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme: hex. value ⁇
  • Subject Public Key- 1 Identifies the digital signature algorithm to be used with the Algorithm Indicator Subject Public Key: ilex, value ⁇ 1 '
  • Subject Public Key 2 Identifies the length of the Subject Public Key Modulus in bytes Length
  • Subject Public Key 1 Identifies the length of the Subject Public Key Exponent in bytes Exponent Length
  • Hash Result 20 Hash of the Subject Public Key and its related information
  • the public key certificate of the terminal is as follows (NF represents the length of the module of the public key of the terminal provider while NT indicates the length of the module of the public key of the terminal):
  • the provider encrypts with its own private key SF the following amount:
  • Terminal 4 Unique terminal identification code (format and management of
  • Hash Algorithm I Identifies the hash algorithm used to produce the Hash Result in the
  • Terminal Public Key 1 Identifies the digital signature algorithm to be used with the
  • Termmal Public Key 2 Identifies the length of the Terminal Public Key Modulus in bytes
  • Terminal Public Key I identifies the length of the Terminal Public Key Exponent in bytes
  • Terminal Public Key - 37 this field consists of the NF - 37 most significant bytes of the
  • Hash Result 20 Hash of the Terminal Public Key and its related information
  • the subject ID is the company code for the Manager and the Terminal Provider ID.
  • the Unpredictable Number is the random number generated and sent to the other party.
  • the string of data that has to be encrypted with the secret key is the fol lowing:
  • the format of the data to be encrypted for key exchange is as follows:
  • Each key must be provided with a "Key type” field indicating the intended use of the key (see table below) and an index that determines the version with respect to its type.
  • the data in the table above are encrypted with the public key of the terminal (PED).
  • the format of the data to be encrypted for sending the check digit of the TDES key is the following: Field Length Description
  • the CRC is placed within the messages (in the field referenced by bit 64 or 128 depending on whether the primary bitmap alone or also the secondary one i s present) and then encrypted along with the entire message.
  • a third and subsequent step involves loading the rest of the data to a buffer
  • a fourth and subsequent step involves executing a shift of the most significant bit of the buffer to the least significant bit of the CRC
  • a sixth and subsequent step involves adding to the original data string (the one without the '0' of step 1) the content of the CRC,
  • the terminals EFT-POS 108 must be able to manage a set of public keys to authenticate microcircuit card data (contact and contactless) according to the specifications of EMV-B2.
  • Each public key of CA (Certification Authority) must be associated with a specific RID and a specific Certification Authority Public Key Index and must also be accompanied by all the necessary elements for the authentication functions of the Issuer's public key.
  • the terminals must allow entering and deleting the public keys and all associated data by remote procedure.
  • Each terminal manager is responsible for configuring only the public keys of CA associated to payment circuits (RID) managed by it in relation to the acquirer subjects for which it works.
  • RID payment circuits
  • the focus of the system object of the present invention is the following: having a protocol that defines:
  • the protocol described herein as regards the management of configurations related to different Acquirers, contemplates that operational and security parameters can be assigned to PSO/EFT payment systems by a plurality of terminal managers and by different acquirers, with a multi acquiring procedure.
  • the terminal must be able to manage multiple sets of security keys disjointly, such as without limitation PINs and message protection, and CA keys for electronic payment card authentication.
  • the terminal must be also able to manage multiple sets of both technical and acquisition parameters.
  • Terminal manager identifier
  • the terminal manager In the context of production deployments and during the configuration and the assignment of access parameters, the terminal manager will have to take into account the above expected behaviors by the payment systems.
  • the GT ID a 7-digit numeric code which uniquely identifies the terminal manager used, must be entered on the terminal.
  • Each of these keys is assigned indicating the type and, especially, the index.
  • connection type connection type, response waiting time, etc.
  • response waiting time connection type, response waiting time, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Electronic transceiving system for exchanging banking data that operates with a plurality of issuer banks ( 102) and the associated operative and authorization centers (103) through which said issuer banks (102) manage a plurality of activities of issuing, wherein the issuer banks (102) receive and transmit electronic data with an interbanking network (104); said electronic system (100) comprises acquirer banks (105) through which said interbanking network (104) transmits and receives electronic data (B), wherein the activities of said acquirer banks (105) comprise also those which are developed under their own responsibility by application centers (107) that transceives electronic data with a plurality of terminal managers (106), which operate as an electronic interface towards a plurality of payment terminals (108) that comprise ATM (109) or POS (110) susceptible of being used by a user (101) which is the owner of an electronic payment card (200); wherein on said payment terminal (108), after a preliminary operation of mutual authentication between payment terminal (108) and each of the terminal managers (106), there is at least one key of protection of messages of services (KSER), not used for performing a financial transaction, wherein said key is managed by said terminal manger authority (106) and an initial key (KIP) used for cyphering a PIN introduced online from said user (101), a key of cyphering of the AP operating a verification of the PEN online for transactions in a third magnetic trace of said electronic payment card and a key for protecting financial messages (KPOS) used for the cyphering of financial messages exchanged between the payment terminal (108) and the terminal manager (106).

Description

"Electronic system of acquisition for transceiving banking data"
Description
Field of the invention
The present invention relates in general to the field of electronic data exchange systems and in detail it relates to an electronic acquisition system for transceiving banking data.
The present invention also relates to an acquisition system for transceiving banking data.
Prior art
In today's banking systems, those operating in the circuit are classified as issuers/acquirers, authorization centers, application centers, terminal managers and POS terminal providers. Such entities must respect certain rules that are necessary to minimize the risks associated with the payment system and to ensure the protection of the stakeholders.
Such systems presently are in need of improvement in order to increasingly protect the security of the stakeholders. The object of the present invention is therefore to describe an electronic system of acquisition for transceiving banking data which allows optimizing the safety of the stakeholders.
Summary of the invention
According to the present invention, an electronic system of acquisition for transceiving banking data is provided, which operates with a plurality of issuer banks 102 and the associated operative/authorization centers 103 through which said issuer banks 102 manage a plurality of activities of issuing, wherein the issuer banks 102 receive and transmit electronic data with an interbanking network 104,
said electronic system 100 comprises acquirer banks 105 through which said interbanking network 104 transmits and receives electronic data B, wherein the activities of said acquirer banks 105 comprise also those which are developed under their own responsibility by application centers 107 that transeeives electronic data with a plurality of terminal managers 106, which operate as an electronic interface towards a plurality of payment terminals 108 that comprise ATM 109 or POS 1 10 susceptible of being used by a user 101 which is the owner of an electronic payment card 200, wherein
on said payment terminal 108, after a preliminary operation of mutual authentication, described hereinafter, between payment terminal 198 and each of the terminal managers 106, there is at least one key of protection of messages of services KSE , not used for performing a financial transaction, wherein said key is managed by said terminal manger authority 106 and an initial ke ·;> used for cyphering a PIN introduced from said user 101 , a key of cyphering of the AP operating a verification of the PIN online for transactions in a third magnetic trace of said electronic payment card and a key for protecting financial messages Kpos used for the cy phering of financial messages exchanged between the payment terminal 108 and the terminal manager 106.
The architectural scheme of generation of the RSA certificate provides a single trusted entity having the role of Certification Authority. In detail , in such a scheme, the CA 122 is hierarchically superior to both the manufacturer terminal 120 and to the GT 121 . The various terminals 108 are managed by the terminal manufacturer 120.
The procedure requires both the terminal providers and the terminal operators to generate a pair of RSA keys and certify their public key at the CA.
The provider, in the process of setup of the terminals, will generate a pair of RSA keys for each terminal (EFT-POS) and certify the public key of the terminal with the private key of the provider.
The terminal manager 106, via crypto device, manages the following quantities:
- One or more master keys KMP for Acquirer (master key for the protection of the PIN) for the derivation of KIP keys (initial key for PEN protection for the EFT-POS terminal);
- A secret key SG;
- A public key PG; - The public key CG certificate obtained by the CA;
- The public keys of the CA (key plus index);
- The Key Serial Number and the KIP.
- A key KSER (generated randomly) for the protection of service messages
- One or more KPOs (generated randomly) for the protection of financial messages
- A random number NRG
The payment terminal 108 manages through its security module the following quantities:
- the secret key of terminal ST;
- the public key of terminal PT;
- the certificate of the public key of provider CF obtained from the CA;
- the certificate of the public key of terminal CT generated by the provider;
- The public keys of the CA (key plus index);
- Random number NRT;
- The KSER;
- The KPOS;
- The different pairs Key Serial Number and KIP
During the installation step of the payment terminal 1.08, or in any case when assigning the first keys, said payment terminal 108 and the terminal manager 106 will exchange the certificates and encrypt with their own private key a random number generated and sent by the other party.
Each subject (terminal manager 106 and payment terminal 108);
- verifies the correctness of the received certificate (expiry date of the certificate included);
- retrieves the public key of the other party;
- generates a random number and sends it to the other party;
- encrypts the random number received from the other party with its own private key;
- decrypts the random number received (encrypted with the private key of the other party ) with the public key of the other party retrieved from the received certificate; - verifies the equality of the decrypted random number with that transmitted.
Said mutual authentication process is carried out by both parties and at the end the two parties will have the public key of the subject with whom they are interacting.
The terminal manager 106 then sends the necessary keys to the terminal by encrypting them with the public key of the terminal. The terminal manager 106 creates a check digit of the keys to be sent and encrypts them using its own private key.
In one aspect of the present invention, said payment terminal 108 releases an AP amount which is cyphered by means of a TDES cyphering algorithm with a fixed key.
In a further aspect of the present invention, said payment terminal 108 comprises means of generation of a data packet containing said PIN, wherein said means of generation are activated for both EMV contact and contact! ess transactions and in second trace, and wherein said payment terminal 108 uses the Format 0 which i s defined in the ISO 9564 standard and encodes it with TDES encoding.
In detail , said initial key KIP is in turn derived from an initial key KMP or master PIN key which is generated in a cyphering device or crypto device 404 which receives in input said KMP electronically and automatically selected in accordance with an identification index (KID) and a random number which is generated by a tamper! ng-resistant device 402.
In detai l, said initial key KIP used for cyphering a PIN introduced online from said user 101 i s generated by means of a couple of DES encoders 501, 502, each receiving in input said KMP; in said couple of DES encoders 501 , 502, the first DES encoder 501 further receives in input a KiD || TRSM ID string and provides in output the first portion of the key Kn , i.e. KipA; the second DES encoder 502, further receives in input the string KID jj TRSM ID inverted, and provides in output the second portion of key KiP, i .e. KiPB, and wherein the key KIP is therefore given by ΚΪΡ = KiPA || KiPB.
Moreover, said payment terminal 108 performs a step of generation of a key of session cyphering KCUR, wherein said key of session cyphering KCUR is generated by means of a cyphering TDES, and in detail wherein said payment terminal comprises a couple of DES encoders 601, 602 wherein said key for protecting financial messages KPOS used for cyphering financial messages exchanged between the payment terminal 108 and the terminals manager 106 is realized by means of said couple of encoders DES 601, 602, wherein together with an identification code of the online operation that i s transmitted on a second input of the first decoder 601 of said couple of DES encoders 601 , 602; said first DES decoder 601 generates in output a first portion of the key of cyphering KCU , that is the portion KCURA, and wherein the same Kpos key is further put in input to a second DES encoder 602, which receives an identification code of the online operation and produces in output a second portion of the key of cyphering KCUR, that i s the portion KCURB, and wherein said key of session cyphering KCUR derives from sequencing the first portion KCURA with said second portion KCURB-
According to the present invention, an electronic acquisition method for transceiving hanking data is also implemented, with a plurality of issuer banks 102 and the respective operative and authorization centers 103 through which said issuer banks 102 manage a plurality of issuing activities, wherein the issuer banks 102 receive and transmit electronic data with an interbanking network 104, which through acquirer banks transmit and receive electronic data (B), wherein the activities of said acquirer banks 105 also comprise those carried out under their own responsibility by the application centers 107 performing an operation of transceiving electronic data with a plurality of terminal manager 106, which operate as an electronic interface to a plurality of payment terminal s 108 that comprise ATM 109 or POS 1 10 susceptible of being used by a user 101 which is the owner of an electronic payment card 200; on said payment terminal 108, after a preliminary operation of mutual authentication, described hereinafter, between payment terminal 108 and each of the terminal managers 106, there is at least one protection key of service messages KSER not used to perform a financial transaction, wherein said key is managed by said terminal manager entity 106 and an initial key KIP used for cyphering a PIN introduced in an introduction step of the PIN on said payment terminal 108 by said user 101, a key of cyphering of the AP for the verification of the PIN online for transactions in a third magnetic trace of said electronic payment card and a key for protecting financial messages Kpos used for the cyphering of financial messages exchanged between the payment terminal 108 and the terminal manager 106.
The architectural scheme of generation of the RSA certificate provides a single trusted entity having the role of Certification Authority, In detail, in such a scheme, the CA 122 is hierarchically superior to both the manufacturer terminal 120 and to the GT 121. The various terminals 108 are managed by the terminal manufacturer 120.
The procedure requires both the terminal providers and the terminal operators to generate a pair of RSA keys and certify their public key at the CA ,
The provider, in the process of setup of the terminal s, wil l generate a pair of RSA keys for each terminal (EFT-POS) and certify the public key of the terminal with the private key of the provider.
The terminal manager 106, via crypto device, manages the following amounts:
- One or more master keys KMP for Acquirer (master key for the protection of the PIN) for the derivation of KIP keys (initial key for PIN protection for the EFT-POS terminal);
- A secret key SG;
- A public key PG;
- The public key CG certificate obtained by the CA,
- The public keys of the CA (key plus index);
- The Key Serial Number and the KIP;
- A key KSER (generated randomly) for the protection of service messages;
- One or more KPOs (generated randomly) for the protection of financial messages;
- A random number NRG
The payment terminal 108 manages through its security module the following amounts:
- the secret key of terminal ST
- the public key of terminal PT
- the certificate of the public key of provider CF obtained from the CA
- the certificate of the public key of terminal CT generated by the provider - The public keys of the CA (key plus index)
- Random number NRT
- The KSER
- The KPOS
- The different pairs Key Serial Number and KIP
During the installation step of the payment terminal 108, or in any case when assigning the first keys, said payment terminal 108 and the terminal manager 106 will exchange the certificates and encrypt with their own private key a random number generated and sent by counterpart.
Each subject (terminal manager 106 and payment terminal 108):
- verifies the correctness of the received certificate (expiry date of the certificate included)
- retrieves the public key of the other party
- generates a random number and sends it to the other party
- encrypts the random number received from the other party with its own private key
- decrypts the random number received (encrypted with the private key of the other party) with the public key of the other party retrieved from the received certificate
- verifies the equality of the decrypted random number with that transmitted.
Said mutual authentication process is carried out by both parties and at the end the two parties will have the public key of the subject with whom they are communicating.
The terminal manager 106 then sends the necessary keys to the terminal by encrypting them with the public key of the terminal. The terminal manager 106 creates a check digit of the keys to be sent and encrypts them using its own private key.
One aspect of the present method, moreover, comprises a step of release, by the payment terminal 108, of an AP amount cyphered by means of a fixed key TDES cyphering algorithm.
In one aspect of the present invention, said payment terminal 108 executes a step of generation of a data packet containing said PIN, wherein said generation step is executed for both EMV contact and contactless transactions and in second trace, and wherein said payment terminal 108 uses the Format 0 which is defined in the ISO 9564 standard and encodes it with TDES encoding.
One aspect of the present method, moreover, comprises a step of derivation of said initial key KIP from an initial key KMP or master key PI generated in a device of cyphering or crypto device 404 which receives in input said KMP electronically and automatically selected in accordance with an identification index KID and a random number generated by a tampering-resistant device 402.
One aspect of the present invention, moreover, comprises a step of generating said initial key KIP used for cyphering a PIN introduced online from said user 101 by means of a couple of DES encoders 501, 502, each receiving in input said KMP; in said couple of DES encoders 501 , 502, the first DES encoder 501 further receives in input a iD j| TRSM ID string and provides in output the first portion of the key KiP, i .e. KIPA, the second DES encoder 502, further receives in input the string KID jj TRSM ID inverted, and provides in output the second portion of key KiP, i.e. KIPB, and wherein the key ]¾P is therefore given by KIP = KIPA l i IPB.
In one aspect of the present method, said payment terminal 108 performs a step of generation of a key of session cyphering KCUR, wherein said key of session cyphering KCUR is generated by means of a cyphering TDES, and in detail wherein said payment terminal comprises a couple of DES encoders 601, 602 wherein said key for protecting financial messages KPos used for cyphering financial messages exchanged between the payment terminal 108 and the terminals manager 106 is realized by means of said couple of encoders DES 601, 602, wherein together with an identification code of the online operation that i s transmitted on a second input of the first decoder 601 of said couple of DES encoders 601 , 602; said first DES decoder 601 generates in output a first portion of the key of cyphering KCUR, that is the portion KCURA, and wherein the same KPQS key is further put in input to a second DES encoder 602, which receives an identification code of the online operation and produces in output a second portion of the key of cyphering KCUR, that i s the portion KCURB, and wherein said key of session cyphering KCU derives from sequencing the first portion CURA with said second portion KCURB-
Description of the figures
The invention will now be described in detail with reference to the appended drawings, which illustrate one or more preferred and non-1 iniiting embodiments; in detail :
- figure 1 shows the operating scheme in which the system object of the present invention operates;
- figure 2 shows an organization scheme of the encryption keys on a terminal EFT-POS;
- figure 3 shows a block diagram of the diversification of key KiP;
- figure 4 shows a block diagram of an encoding of two partial keys by means of RSA encoders,
- figure 5 shows a further block diagram of an encoding of two partial keys by means of RSA encoders;
- figure 6 shows a hierarchical block diagram between a certification authority, a plurality of POS or ATM terminals operated by a single manufacturer together with a terminal operator manager;
- figure 7 shows a block diagram of initial loading of the keys. Detailed description of the invention
With reference to figure 1, reference numeral 100 indicates as a whole an electronic system for transceiving banking data.
In system 100 there is a user 101 who uses a BANCOMAT®/PagoBANCOM AT® card 200 to make an electronic payment.
More generally, the BANCOMAT® PagoBA"NCOMAT® card 200 is an electronic payment card with a raicrocircuit and magnetic stripe. The standards to which these cards refer are ISO/IEC-7816 concerning contact electronic identification cards, ISO/iEC 781 1 and EMV standards. In the typical magnetic stripe there are three recording tracks; - the third is enabled for both reading and writing and ATMs have the option of changing the content thereof during the operations. The BANCOMAT®/PagoBANCOMAT® cards use the third track.
The user 101 interacts with an issuer bank 102, which manages a plurality of issuing activities including the authorization ones also made through an operative/authorization center 103; the issuer bank 102 receives and transmits electronic data with an interbanking network 104. The transmission and reception of electronic data exchanged with the issuing system is schematically indicated in figure 1 by arrow A.
In addition, the interbanking network 104 receives and transmits electronic data with an acquirer bank 105; the transceiver of said electronic data is schematically indicated in figure 1 by arrow B.
In detail, the activities carried out under the responsibility of the acquirer bank 105 also include those carried out under their own responsibility by the application centers 107 that transceive electronic data with a plurality of terminal managers 106, which operate as an electronic interface to the payment terminals 108 which include, as illustrated in figure 1 , ATM 109 or POS 1 10.
According to the present invention, by POS it is meant an electronic device and the respective banking service that allow a creditor to accept and collect directly on their current account, electronic payments by means of electronic money, or by credit, debit and prepaid cards by the debtor customers.
According to the present invention, the double vertical bar operator jj refers to an operation of sequencing or concatenation of multiple bits.
At the time of payment, after the insertion of the card into the terminal (or its simple approach, if contactless technology is used), an exchange of messages between devices/entities is activated, in order to verify whether or not to authorize the payment itself. These messages are representative of the above electronic data.
The above exchange of messages is regulated in each segment by the Consorzio BANCOMAT®. In particular, said exchange of messages guarantees both the safety of the circuit and the possibility of offering multi acquiring solutions.
At an operational level, system 100 object of the present invention defines mechanisms for the protection of data exchanged by the terminal EFT-POS 1 10 with the acquirer bank 105, the minimum requirements for the quantities of security, their use and their management and presents a remote loading mode of such quantities on the terminal EFT-POS 1 10 (key management) with the use of mutual authentication, digital certificates and asymmetric keys. In particular, system 100 object of the present invention seeks to overcome some security limits in the section between the POS terminal and the terminal manager which are typical of systems operating according to the IS08583 standard.
In order to allow proper management of the communication between POS and host, compared to the ISO 8583 standard, some important aspects of the messages, and thus of the electronic data exchanged vary. These variations are made necessary by the fact that the protocol is defined between "card acceptor" and "terminal manager", and not between "acquirer" and "issuer" as provided for by IS08583.
To this end, a header has been introduced in the messages which provides a series of information adapted to identify the sender and the recipient of the message and other information necessary to the proper management of the message itself.
The protocol defines:
- The management of the parameters which determine the operation of the terminal
- Messages for the payment authorization request (online/offline, chip with contacts/contact! ess/contact band)
- Messages for reversal and service operations (receipt, total and accounting closing management)
- Error management
The aspects that most characterize the protocol are:
- The ability to manage the mutual authentication between terminal and terminal manager
- The ability to manage configurations relating to different acquirers.
In the context of the present invention, some acronyms will be used. In particular, AID means the application identifier which identifies the application present on a chip card, AIID means Acquirer Identification, and identifies an acquirer of payment cards within the terminal.
CA means Certification Authority, which is the entity that manages digital certificates.
CRC means Cyclic Redundancy Check, which represents the method for generating a checksum for verifying the integrity of electronic data.
CVM means cardholder verification method and is therefore defined as the verification method of the cardholder,
DOL means Data Object List and is a list of data in TLV format.
DIJ PT means Derived unique Key per Transaction, namely the key derivation method for symmetric algorithms.
GT or manager means terminal manager, which represents the front end of the acquisition infrastructure to the terminals EFT-POS 110. In particular, for the purposes of the present invention, it is assumed that the GT can manage the security functions on behalf of one or more acquirers.
IFM means interface module, i .e. a smart card reader interface module.
KID means Key Identifier, which is the key index.
PED means Pin Entry Device, which represents the device for entering the PIN.
RID means Registered Application Provider Identifier, which in the context of the present specifications uniquely identifies a payment card network.
TDES means Triple DES, namely, a mode of use of the DES algorithm with double or triple- length keys.
TLV means Tag Length Value, which is the data representation format.
Finally, TMS means Management Terminal System, which represents the remote management sy stem of the terminals provided by the manufacturer.
In the present invention, the following notations are also used:
C,' Terminal manufacturer digital certificate generated by CA
Cg GT digital certificate generated by CA
Ct Terminal EFT-POS digital certificate generated by the manufacturer LSB Less significant byte
MSB Mosi Significant Byte
GTid GT Identifier
tmisis Terminal Identifier
Kip 128-bit initial key for PIN encryption, per single terminal
Kmp 128-bit TDFS master key used to derive the Kip key
Kmpb 128-bit key for transaction used for PIN encryption
Kpos Unique 128-bit key for transaction used for message encryption
Pea RSA key public component of the Certification Authority
Pf RS A key public component of the terminal manufacturer
Pg RSA key public component of the GT
Pi RSA key public component of the single terminal
ScA RSA key private component of the Certification Authority
Sf RSA key private component of the terminal manufacturer
.a RSA key private component of the GT
Si RSA key private component of the single terminal
The object of the present document is to also describe the security aspects for financial transactions on the terminals EFT-POS 110. In particular, the document defines the mechanisms for the protection of data exchanged by the terminal EFT-POS 110 with the acquirer, the minimum requirements for the quantities of security, their use and their management and presents a remote loading mode of such quantities on the terminal EFT- POS (key management) with the use of mutual authentication, digital certificates and asymmetric keys.
The terminals EFT-POS 10 can operate in any of the three present operating modes:
- standalone;
- self-service; and
- distributed.
In order to ensure the confidentiality of data used in financial transactions and of messages exchanged, the terminal EFT-POS must handle secret encryption keys that are used with a Triple DES (TDES) symmetric algorithm.
The diagrams for the management of symmetric keys used for financial applications require, inter alia:
- procedures for the safe loading of an initial key on the terminal;
- algorithms for the evolution or diversification of the keys at each use thereof;
- mechanisms for the identification or indexing of the keys, so that they can either be used either for a specific function or to allow the other entity to use the correct key.
The solutions to manage the security of transactions are based on the functional requirements expressed in the documentation of the Consorzio BANCOMAT® SPE-DEF-122 [5] in relation to the security of the acceptance network, and in particular:
- mutual authentication between the two entities involved in the assignment of the initial keys, to ensure the authenticity of the keys used (the keys come from an authenticated entity and are intended for an authenticated terminal); his document presents a procedure based on the use of RSA keys;
- ability to manage the keys separately for each acquirer enabled on the terminal, even when a single entity (GT) is used for the key assignment;
- separation between the PIN protection keys and the message protection keys;
- minimum length of the keys for TDES algorithm of 128 bits;
- integrity of the messages exchanged.
In order to achieve these objects, in system 100 object of the present invention, the types of keys present on the terminal EFT-POS are the following:
1. Key for the protection of service messages KSER (key assignment, parameter assignment, totals, etc) not used for financial transactions, independently of the Acquirer and managed by the Terminal Manager.
2. Initial key used to encrypt the PIN sent online for its verification by the issuer (KIP).
3. AP key encryption for the verification function of the online PIN for third trace transactions.
4. Key for the protection of financial messages (Kpos) used for the encryption of financial messages exchanged between the terminal and GT, independently of any additional protections provided for at the transport protocol level.
The key architecture is defined to allow, on the terminal EFT-POS 110, more acquirers to enter their own keys using a single GT and allow terminal 108 to communicate with more than one GT. It is noted that the management of multiple Acquirers by the terminals is not compulsory. A subdivision at a logical level is thus present on the terminal of keys for acquirers and for GT, according the general scheme shown in figure 2, Each manager 301-303 therefore configures a service message protection key and additional financial message protection keys. The keys are sent with the respective indexes used for their unique identification. When assigning the acquisition parameters, the Manager must define for each acquirer the key index for the encryption of financial messages that the terminal will have to use during the transactions.
In particular, each key is referenced by an index that identifies both the GT and the acquirer, using index '0' by convention to indicate messages without encryption.
The functions that provide for the management and use of symmetric keys and that will be described separately in the present document therefore are:
- the PIN encryption for its online transmission;
- the encryption of messages between terminal EFT-POS 110 and GT;
- the initial key assignment mode on the terminals EFT-POS 110.
For the integrity of the messages, a mechanism is used that is based on the calculation of a CRC as described in the following part of the description and the TDES encryption of all data of the CRS message included.
The general requirements that the terminal EFT-POS must comply with for the management of the online PIN are defined in the IS09564 [8] standard, in particular Part 1. Inside the PED (Pin Entry Device), the PIN will be included in a package (PIN Block) which will be encrypted according to the rules defined in this chapter, depending on the type of transaction. The encrypted PIN Block will be sent by the terminal EFT-POS to the GT in the authorization messages.
As regards the format of the Pin Block for EMV transactions, for all types of EMV transactions (contact and contactless) which require the online Pin verification, the terminal must use the Format 0 defined in IS09564 [8] to build the package containing the PIN (PIN Block), which will then be encrypted in TDES mode as specified hereinafter.
Pin Block format for transactions in third track (AP) For third magnetic track transactions for PagoBANCOMAT® cards, the terminal must build the PIN Block using the AP calculation algorithm. The quantity AP must be calculated within the PED and TDES encrypted with fixed 128 bit key (does not change at each transaction).
In no case the quantity AP must be released in clear by the PED, The encrypted AP is sent in field 52 in the authorization request messages.
PIN Block encryption mode
The encryption of the PIN Block must occur with TDES mode with 128-bit keys.
For the evolution of the keys, reference is made to the DUKPT method, defined in the X9.24 standard that involves the use of an initial key KIP, derived in turn from an initial key KMP (Master Pin key) inserted/generated in the crypto device. The DUKPT contemplates that after each PIN Block encryption operation, the keys that will be used for the next encryption are derived and the keys previously used are deleted in the PED,
The key KMP is identified by an index Key Set Identifier (KID), It is required that each Manager differs the keys KIP for each terminal.
The diversification process of the key KIP can be schematized as shown in figure 3, In detail, the key KiP comprises a 3 -byte KSI 401 and a TRSM ID 402 which is a random number of the length, preferably but not limited to 4 bytes.
In detail, a plurality of files of protected keys Ki, KMP, K3,... ,Kn 403 derive from the KSI 401 which are under the Local Master Key in the crypto device 404, which comprises a first module TDES 405 and a second module KiP 406, The KMP selected on the basis of Km is transmitted to the TDES 405,
The operations of generation of the KMP and the derivation of the KIP must be carried out through a secure cryptographic device as defined in [10]. The string consisting of the KID and TRSM ID must be filled to the right with a byte '80' for the TDES encryption operation for the derivation of the ΚΪΡ.
Figure 4 shows a block diagram of the derivation of key I¾p. In detail, the MP is sent in input to a DEA or DES encoder 501 , which also receives at its input KID |j TRSM ID and outputs the first key Kn , i.e. KIPA- Likewise, the KMP is sent in input to a second DEA or DES encoder 502, which also receives at its input KiD jj TRSM ID, hut this time reversed, and outputs the second key KiP, i.e. KIPB.
The key ΚΪΡ is thus given by KIP = KiPA |j KIPB
Together with the key KIP, the acquirer also sends the index KiD of the key KMp and the KSN
(Key Serial Number) associated with the KIP counter valued at zero.
The KSN is 10 bytes long and has the format shown in the following table:
Figure imgf000019_0001
The KSN field must be unique per Manager and for each initialization of each terminal. The terminal manager may possibly assign a KIP and KSN pair for each set of acquisition parameters configured, using different KMP for each acquirer (KMP with different ID). The terminal must select the KIP to be used, based on the key index associated by the Manager with the Acquirer that has been identified for the specific transaction.
The Manager identifier will be sent to the terminal in the key assignment step.
The field KSN (whose subfield counter is incremented by the PED) is sent in field 53 of the authorization messages. The encrypted PIN-Block is sent in field 52.
As regards the protection of data exchanged between POS 110 and manager, all messages exchanged between GT and POS must be TDES encrypted with 128~bit double key with the exclusion of the messages related to the mutual authentication and for the assignment of the service KSER, which is transmitted encrypted as specified in chapter 8.
All encryption keys of the messages must be managed by the GT and by the terminal as required by the ISO 1 1568-1 standard. The GT must assign the message encryption keys. Together with the keys, the GT also sends the respective index, which must be valued in the header of all messages exchanged between POS and GT.
The terminal then only for the financial transactions (messages 1 1x6, 12x6, 14x6 and confirmations 8xx6) must select the KPos to be used on the basis of the index associated to the acquirer identified for the specific transaction. This index must be valued by the terminal in the header of the financial message.
For all other types of transaction, the terminal will use the service KSER assigned in the mutual authentication process. The terminal starting from the Kpos (the same mechanism should be used for the diversification of the KSER) must derive a session key, Kcur, to encrypt the current message.
The diversification must be made through TDES encryption of the Online operation ID' field in the header of the messages through the KPos-
Figure 5 shows a block diagram of a diversification to obtain the current encryption key Kcur. In detail, the key KPos is placed in input to a first encoder DEA or DES 601, together with an identification code of the online operation which is instead transmitted on a second input of the same first decoder. Said first decoder DEA or DES 601 generates at its output a first portion of the encryption key KCUR, i .e. the portion KCURA- The same key KPQS is also put in input to a second DEA or DES encoder 602, which like the first encoder 601 receives an identification code of the online operation. The second DEA or DES encoder 602 produces at its output a second portion of the encryption key KCUR, i.e. the portion KCURB- In detail, the applicant points out that the value Online operation identifier' (n6 format in 3 bytes) must be aligned to the right and filled with 5 bytes of '00' hex to the left so as to obtain an 8-byte block. The encryption of this block with the KPOs determines the component KQUA of the new session key that will be used to encrypt the current message. The 8-byte block consisting of the Online operation ID' formatted as described must be reversed through xor operation with an 8-byte 'FF' hex block.
The block thus reversed must be encrypted with the KPOS to obtain the KCurB component of the new session key.
The 128-bit session key Kcur to be used in the current transaction and consisting of the concatenation of the two keys obtained from the TDES encryption operations:
Kcur :=: KcurA i ! KcurB The terminal must encrypt the entire message. Header and Message Type Identifier excluded.
At the level of encryption mode, this must be as already mentioned of the TDES type and should be performed in CBC mode with Initial Vector =;: 0.
If the length of the data to be encrypted is not a multiple of 8 bytes, the last block must be filled with a '80' hex and a sequence of bytes '00' to have an 8-byte block.
If the length of the data to be encrypted is a multiple of 8 by tes, the following 8-byte block in hexadecimal encoding must be added: '80 00 00 00 00 00 00 ()()'.
The assignment of the keys in the terminal POS 110 must be made after a mutual authentication between terminal 108 and the Manager.
The mutual authentication must be carried out by means of a 2-level public key structure (PKI) with a third trusted entity for the management of digital certificates (CA) as shown in figure 6.
The architectural scheme provided in the present document provides for a single trusted entity having the role of Certification Authority with certificate format defined in the following parts of the present description. In detail, the CA 122 is hierarchically superior to both the manufacturer terminal 120 and to the GT 121. The various terminals 108 are managed by the terminal manufacturer 120.
This ensures the respect of specific safety requirements for the problems object of the present document and the management of any critical issues related to the impairment of keys or security procedures for the management of the POS terminals.
The procedure requires both the terminal providers and the GT to generate a pair of RSA keys and certify their public key at the CA.
The terminal provider, in the process of setup of the terminals, will generate a pair of RSA keys for each terminal (EFT-POS) and certify the public key of the terminal with the private key of the provider.
Therefore, the Manager, using the crypto device, must manage the following quantities:
- One or more master keys KMP for Acquirer (master key for the protection of the PIN) for the derivation of KIP keys (initial key for PIN protection for the EFT-POS terminal);
- A secret key SG;
- A public key PG;
- The public key CG certificate obtained by the CA;
- The public keys of the CA (key plus index);
- The Key Serial Number and the KIP;
- A key KSER (generated randomly ) for the protection of service messages
- One or more KPOs (generated randomly) for the protection of financial messages,
- A random number NRG
The terminal provider must manage through its crypto device:
- the secret key of provider SF
- the public key of provider PF
- the certificate of the public key of provider CF obtained from the CA
The terminal must manage through its security module the following quantities;
- the secret key of terminal ST
- the public key of terminal PT
- the certificate of the public key of provider CF obtained from the CA
- the certificate of the public key of terminal CT generated by the provider
- The public keys of the CA (key plus index)
- Random number NRT
- The KSER
- The KPOS
- The different pairs Key Serial Number and KIP
During the installation step of the terminals, or in any case when assigning the first keys, the terminal and the terminal manager must exchange the certificates and encrypt with their own private key a random number generated and sent by the other party.
Each subject (Manager and terminal) will:
- verify the correctness of the received certificate (expiry date of the certificate included) - retrieve the public key of the other party
- generate a random number and send it to the other party
- encrypt the random number received from the other party with its own private key
- decrypt the random number received (encrypted with the private key of the other party) with the public key of the other party retrieved from the received certificate
- verify the equality of the decrypted random number with that transmitted.
This process must be carried out by both parties and at the end the two parties wi ll have the public key of the subject with whom they are interacting.
The manager at this point can send the necessary keys to the terminal by encrypting them with the public key of the terminal (PED). To guarantee the Manager origin, the latter must create a check digit of the keys to be sent and encrypt them using its own private key.
As illustrated in figure 7, the crypto device 404 exchanges data with acquirer 130 which in turn transmits to CA 122 the public component of the RSA key of the GT PQ and receives from the CA 122 the digital certificate CG together with the public component of the RSA key of the CA 122. In turn, the CA122 communicates with a further crypto device 404. The CA 122 transmits the digital certificate of the terminal manufacturer CF and the public component of the RSA key of the CA 122 PCA to Provider 135 and receives from the latter the public component of the RSA key of the terminal manufacturer PF. Provider 135 transmits and receives electronic data in turn with a further crypto device 404.
Provider 135 also communicates with a terminal EFT-POS 108 by transmitting and receiving, respectively, to and from the latter, the digital certificate of terminal EFT-POS 108 CT generated by the manufacturer, the digital certificate of the manufacturer CF and the public component of the RSA key PCA of the CA 122, and receives the public component of the RSA key of the single terminal Pr.
The pair of RSA keys of the GT must be generated via crypto device.
The minimum length of the keys must be 2048 bits.
The key management procedures adopted must comply with what set forth in the specifications of the Consorzio BANCOMAT® SPE-DEF-074, if applicable to the present context and referred only to key management, and in particular the following aspects should he covered and documented;
- Management of relations with the personnel in charge of key management
- Access control system to the place where key management is performed (identification of inspectors and access date)
- Management of the access keys to the key management place
- Access to the key management place
- Control room for the management of alarms and CCT V of the key management place
- CCTV for the security environment for key management
- Alarms for the security environment for key management
- Maintenance of the above systems
- Traceabiiity of procedures regarding access control, operations in the security environment for key management, alarms and CCTV reports
- Key management activities as regards: identification of personnel and operating procedures, operational protocols and interfaces with external parties (subcontractors and end clients)
- Physical anti -intrusion requirements of the security place where key management is performed
- Logical anti -intrusion requirements for key management procedures
- Any packaging safety features for shipments
- Signaling of theft or loss of the terminals
The principle of dual control must still be respected in the performance of key management activities and no unauthorized person can gain access to specific amounts of security. The secret key must be protected by a crypto device and should never be clear outside of the device.
The acquisition procedure of the Certificate of the public key of the manager as well as the acquisition of the public key of CA and the use of said security amounts by the Manager must be carried out as provided in the operating manuals of the CA of the Consorzio BANCOMAT® and the security criteria described therein but in any event, it is mandatory to verify, by means of a cryptographic device, the integrity and origin of the same amounts before their operational use which must be limited to the intended purpose in relation to the rules of CA.
Therefore, the public key of the CA of the Consorzio BANCOMAT® and/or the relative amount of control will have to be stored in special archives protected with a key in turn produced/protected by cryptographic device.
Upon completion of the acquisition procedure within the manager's security system, it will not be possible to alter the certificates or the public keys of the CA of the Consorzio BANCOMAT® acquired without this event being detectable by the use of the crypto device 404 and of the keys used in the acquisition step.
The certificate management system must be such as to ensure the division of the same for the specific purpose for which they are intended.
The operations of key management also include recording the destruction procedures of security amounts become obsolete and of key compromise situation management.
The CA will notify the Managers about the revocations of their keys and the Providers key certificates.
With regard to the generation of the Provider's pair of keys, the management of certificates and of public keys of the CA, the generation of terminal pairs of keys and the terminal public key certification activities, the requirements expressed in the previous chapter concerning the requirements of the security environment for key management apply.
The provider must, for each terminal, generate a pair of keys RSA with a minimum length of 2048 bits.
The generation of these keys must be made from the security module of the terminal must provide for the export of the public key of the terminal and the acquisition of the terminal certificate, the Provider's certificate and the public key of the CA of the Consorzio BANCOMAT®, Alternatively, the provider may generate the pair of keys RSA of the terminal through its own crypto device and then load these amounts together with the certificates in the terminal security module. Such operations must he carried out with the same security criteria illustrated for the generation of the pairs of keys of the Manager and the Provider.
Provider 135 must generate the terminal certificate through the use of a crypto device and its own secret key.
All the operations listed must be carried out in a safe environment according to the requirements expressed in the previous chapter. The use of the functionalities shown must be registered and allowed only to authorized inspectors. The operation must be such that the presence of at least two inspectors is required.
Provider 135 should use its own pair of keys and the respective certificate of the public key to initialize up to 5000 terminals and in any case not use it for a period exceeding one year. The structure of the certificates used is that defined in the ISO 9796-2 standard and is the same used in the EMV standard for the offline authentication of the cards and for the interbanking key exchange.
The Certification Authority of the Consorzio BANCOMAT® should create a hash with algorithm SHA-1 FIPS 180-1 (ISO 101 18-3) of data shown in the following table, where NCA indicates the length of the public key module of the Certification Authority and NI the length of the public key module of the applicant.
Field Len th Description
Certificate Format 1 Hex, value OB'
Subject 4 Manager Company Code (company code format aligned to the left identification and filled to the right wi th hex FFF) or Terminal Supplier identifier
Number (managed by the CA on 4 byte).
Certificate Expiration 2 MMYY certificate expiration date
Date
Certificate Serial 3 Binary number unique to this certificate assigned by the Number certification authority
Mash Algorithm 1 Identifies the hash algorithm used to produce the Hash Result in indicator the digital signature scheme: Hex. Field Length Description
value '01'
Subject Public Key I Identifies the digital signature algorithm to be used with the Subject
Algorithm Public Key: hex. value ΌΓ
Indicator
Subject Public Key Identities the length of the Subject Public Key Modulus in bytes Length
Subject Public Key- I Identifies the length of the Subject Public Key Exponent in bytes Exponent Length
Subject Public Key or NCA-37 If Ni < NCA - 37, this field consists of the full Subject Public Key- Leftmost Digits of the padded to the right with NCA - 37 - Ni bytes of value ΈΒ'. If Ni > Subject Public Key NCA - 37, this field consists of the NCA - 37 most significant bytes of the Subject Public Key
Subject Public Key O orNi - NCA+ This field is only present if Ni > NCA - 37 and consists of the Ni - Remainder 37 NCA + 37 least significant bytes of the Subject Public Key-
Subject Public Key- 1 or 3 Subject Public Key Exponent equal to 3, or 2 16 + 1
Exponent
CA 122 encrypts with its own private key SCA the following amount:
Field Length Description
Header 1 Hex. value oA1
Certificate Format 1 Hex. value OB'
Subject 4 Manager Company Code (company code format aligned to the
Identification left and filled to the right with hex FFF) or Terminal Supplier
Number Identifier (managed by the CA on 4 byte).
Certificate Expiration 2 MMYY certificate expiration date
Date
Certificate Serial Number 3 Binary number unique to this certificate assigned by the certification authority
Hash Algorithm Indicator 1 Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme: hex. value ΌΓ
Subject Public Key- 1 Identifies the digital signature algorithm to be used with the Algorithm Indicator Subject Public Key: ilex, value Ό 1 '
Subject Public Key 2 Identifies the length of the Subject Public Key Modulus in bytes Length
Subject Public Key 1 Identifies the length of the Subject Public Key Exponent in bytes Exponent Length
Subject Public Key o Nca-37 If Ni < NCA - 37, this field consists of the full Subject Public Key- Leftmost Digits of the padded to the right withNLA - 37 - Ni bytes of value 'BB'. If Ni > Subject Public Key- NCA - 37, this field consists of the NCA - 37 most significant bytes of the Subject Public Key
Hash Result 20 Hash of the Subject Public Key and its related information
Trailer 1 Hex. value 'BC
The public key certificate of the terminal is as follows (NF represents the length of the module of the public key of the terminal provider while NT indicates the length of the module of the public key of the terminal):
Figure imgf000028_0001
The provider encrypts with its own private key SF the following amount:
Field Lesigth Description
Header 1 Hex. value '6 A'
Certificate Format 1 Hex. value OC
Terminal 4 Unique terminal identification code (format and management of
Identification this data is defined by each supplier)
Number Certificate Expiration 2 MMYY certificate expiration date
Date
Certificate Serial Binary number unique to this certificate assigned by the
Number manufacturer
Hash Algorithm I Identifies the hash algorithm used to produce the Hash Result in the
Indicator digital signature scheme: Hex. value Ό Γ
Terminal Public Key 1 Identifies the digital signature algorithm to be used with the
Algorithm indicator Terminal Public Key: Hex. value ΌΓ
Termmal Public Key 2 Identifies the length of the Terminal Public Key Modulus in bytes
Length
Terminal Public Key I identifies the length of the Terminal Public Key Exponent in bytes
Exponent Length
Terminal Public Key or N v - 3 7 If Ντ < NF - 37, this field consists of the full Terminal Public Key-
Leftmost Digits of the padded to the right with NF - 37 - NT by tes of value 'ΒΒ'. If NT > NF
Terminal Public Key - 37, this field consists of the NF - 37 most significant bytes of the
Terminal Public Key-
Hash Result 20 Hash of the Terminal Public Key and its related information
Trailer 1 Hex. value 'BC
The following is the fomiat of the data that must be signed by the parties for authentication and key exchange.
Signature of the random number
The data that the terminal (PED) and the host must encrypt with their private key to be sent to the other party for authentication are as follows:
- Subject ID
- Unpredictable number
Where the subject ID is the company code for the Manager and the Terminal Provider ID. The Unpredictable Number is the random number generated and sent to the other party. The string of data that has to be encrypted with the secret key is the fol lowing:
Field Length Description
Header 1 Hex value:'00'
Block Type 1 Hex value: '02'
Padding String Ns-3 -4-8-7 Generated pseudorandom (no byte = 001)
Separator 1 Hex value: '00'
Subject identifier 4 Company code (filled to the right with
'!·'}·'}·" ! of the manager or Terminal Supplier Identifier
Homologation certificate 7 Numerical part of the homologation certificate
(e.g. 30101006000001 or 40501006000001)
Unpredictable 8 Random number generated by the host
number or the terminal Key encryption
The format of the data to be encrypted for key exchange is as follows:
Figure imgf000030_0001
Each key must be provided with a "Key type" field indicating the intended use of the key (see table below) and an index that determines the version with respect to its type.
The data in the table above are encrypted with the public key of the terminal (PED).
The types of keys currently contemplated for POS terminals are as follows:
Figure imgf000030_0002
The format of the data to be encrypted for sending the check digit of the TDES key is the following: Field Length Description
(½ bytes)
Header 1 Hex value: '00'
Block Type 1 Hex value: '02'
Padding String Ns-6 Generated pseudorandom (no byte = 00)
Separator i Hex value: '00'
Key cheek digit 3 The check digit is given by the first 3 (most significant) bytes of tlie result of the TDES ECB encryption with the key transmitted of an 8-byte string of '00' hex
Data integrity is guaranteed as a CRC is used on the whole message starting from the header included and the TDES encryption of the entire message with a 128-bit key.
The CRC is placed within the messages (in the field referenced by bit 64 or 128 depending on whether the primary bitmap alone or also the secondary one i s present) and then encrypted along with the entire message.
At a CRC calculation level, the following steps are used:
- a first step i s to add the following two bytes to the data of which the CRC must be calculated: 0000 0000 0000 0000,
- the next step involves loading the registry of CRC (CRCJHIGH and CRCJLOW) with the first two bytes of data;
- a third and subsequent step involves loading the rest of the data to a buffer;
- a fourth and subsequent step involves executing a shift of the most significant bit of the buffer to the least significant bit of the CRC,
- a fifth and subsequent step involves checking if the most significant bit of the CRC (the one before the shift) is T and then execute an xor with the polynomial CRC- 16 (1000 0000 0000 0101 P(x) =;: x 16 + x 15 + x 2 +1 ); if the most significant bit is Ό', start again from Step 4 unti l ail data bits are processed (including the '0' added in step 1),
- a sixth and subsequent step involves adding to the original data string (the one without the '0' of step 1) the content of the CRC,
Finally, as regards data permissions for offline cards, the terminals EFT-POS 108 must be able to manage a set of public keys to authenticate microcircuit card data (contact and contactless) according to the specifications of EMV-B2.
Each public key of CA (Certification Authority) must be associated with a specific RID and a specific Certification Authority Public Key Index and must also be accompanied by all the necessary elements for the authentication functions of the Issuer's public key.
The terminals must allow entering and deleting the public keys and all associated data by remote procedure.
Each terminal manager is responsible for configuring only the public keys of CA associated to payment circuits (RID) managed by it in relation to the acquirer subjects for which it works.
After entering each key and each time the terminal is switched on, all data related to the same must be checked by checking the check digit associated with them. If an error is detected in one or more of the CA keys stored, the terminal must request the assignment of ail parameters (DLL).
In summary, the focus of the system object of the present invention is the following: having a protocol that defines:
- The management of the parameters which determine the operation of the terminal
- Messages for the payment authorization request (online/offline, chip with contacts/contactless/contact band)
- Messages for reversal and service operations (receipt, total and accounting closing management)
- Error management
- The ability to manage the mutual authentication between terminal and terminal manager
- The ability to manage configurations relating to different acquirers.
In particular, the protocol described herein, as regards the management of configurations related to different Acquirers, contemplates that operational and security parameters can be assigned to PSO/EFT payment systems by a plurality of terminal managers and by different acquirers, with a multi acquiring procedure.
If multi -manager, the terminal must be able to manage multiple sets of security keys disjointly, such as without limitation PINs and message protection, and CA keys for electronic payment card authentication. The terminal must be also able to manage multiple sets of both technical and acquisition parameters.
In particular, as will be described in more detail hereinafter, it is defined that the separation of security domains is possible for different terminal managers, in particular by defining the use of the index key to manage the key version within the same type.
In detail, the following is contemplated
1. the assignment of one or more keys with identical type and index, by the same GT, for more than one Acquirer: the payment system must discard all the Acquirers hat have been sent after the first, sending a message 1316 with Action Code valued at '306',
2. Assignment of different keys with the same index and for a specific Acquirer: the payment system must store the keys assigned according to the following 3-parameter model:
1. Key index;
2. Key type;
3. Terminal manager identifier;
3. Assignment of one or more keys with identical type and index, by different GT: the payment system must store the sets of keys assigned, according to separate domains per Terminal Manager;
4. Assignment of a key of same type and same index of other key previously assigned; as for case 1, the payment system must reject (by sending a reply message 1816 with Action Code valued at '860') the new key, if received in the same Dll or in the scenario of subsequent Dll,
5. Unused Acquirer key management; in order to standardize and optimize the behavior of the terminals in the case of keys stored but not used, and considering the impossibility to delete obsolete keys on the Terminal Manager end, the following behaviors of the terminals are defined:
a. Revoking Acquirers: when an Acquirer is revoked, the terminal must autonomously provide to deleting the keys associated with it;
b. Changing indexes associated with an Acquirer: considering the constraint that the same key index cannot be sent to multiple Acquirers by the same Terminal Manager, it is necessary that these indices cannot be transferred from one Acquirer to a different one configured on the terminal, under the normal operation of the same. If such a need becomes urgent, this must be managed only by activating a first Dll;
c. Inability to store new keys by the terminal, due to full memory: upon the occurrence of this condition, and there being no command for the terminal which allows the partial deletion of the keys, the terminal must stop its operations deleting all the security keys contained in the memory, and reacquire its operations only by resorting to a First Dll operation.
In the context of production deployments and during the configuration and the assignment of access parameters, the terminal manager will have to take into account the above expected behaviors by the payment systems.
In a practical example, during installation, the GT ID, a 7-digit numeric code which uniquely identifies the terminal manager used, must be entered on the terminal. As said above, it is possible to enter multiple GT ID, so as to communicate with multiple Terminal Managers, of course by selecting in advance to any transaction (whether payment or configuration) which GT ID to use.
Therefore, we can enter the GT ID 001001 1 on the terminal and make a first DLL, through which we will have from the GT 0010011 the assignment of the CA keys, the PIN protection keys, the AP and the financial messages.
Each of these keys is assigned indicating the type and, especially, the index.
Moreover, the technical parameters (connection type, response waiting time, etc.) are assigned by the GT ID 001001 1 according to the following table:
TAG Description
DF23 Enabling terminal functions 9F1 A Country code
5F2A Currency code
9F 15 Goods category
DF28 LOG forwarding mode
DF29 Time-out terminal O
FF05 Connection parameters GT l st/2nd attempt
FF06 Connection parameters GT 3rd attempt
FF07 Connection parameters to remote management center
FF08 Remote management mode
Finally, from the GT ID 001001 1 , one or more Acquirers ma the fol lowing table:
TAG Description
9F01 Acquirer ID
DF38 Acquirer name
DF34 Key index for P!N-Block protection
DF35 Key index for AP protection
DF31 Key index for financial message protection
FF0D Magnetic stripe PagoBA COMAT® parameters
DF6A Service ID
DF49 Service name
DF3 A Magnetic stripe PagoBANCOM AT® functionality bitmap
FFOA Magnetic stripe application data to other payment circuits DF6A Service ID
DF49 Service name
DF3B Floor limit 1 (for magnetic stripe) DF48 Random selection (for magnetic stripe) DF39 B IN Table
DF57 Magnetic stripe functionality enabled bitmap
FF09 Contact EMV payment application data
DF6A Service ID
DF49 Service name
9F06 Application IDentifier (AID)
DF33 Chip functionality enabled bitmap
9F09 Application Version Number
FFOE Contactless EM V payment application data
DF6A Cless service ID
DF49 Cless service name
9F06 Application IDentifier (AID) Cless
Therefore, in practice:
GT ID 001001
(Acquirer ID) ACQUIRER 34
(Acquirer name) Sxxx
001 1 1 pin block key
001 12 AP key
001 13 financial message key
STRIPE PAGOBANCOMAT SERVICE ID 01234
CHIP PAGOBANCOM AT AID 000141
Acquirer 2 AID 00000
Circuit xx
AID 099999
CLES S P A GOB AN C OM A T AID 004141
GT ID 001001
(ID acquirer) ACQUIRER 98
(Acquirer name) Byy
00156 pin block key
00157 AP key
00158 financial message key
CHIP PAGOBANCOMAT
AID 000141
Circuit two
AID 00001
Circuit zz
AID 663322
Circuit xy
AID 999999
Finally, it is clear that additions, changes or variants may be made to the object of the present invention which are obvious to a man skilled in the art, without departing from the scope of protection that is provided by the appended claims.

Claims

Claims
1 . Electronic system of acquisition for transceiving banking data that operates with a plurality of issuer banks (102) and the associated operative/authorization centers (103) through which said issuer banks (102) manage a plurality of activities of issuing, wherein the issuer banks (102) receive and transmit electronic data with an interbanking network (104),
said electronic system (100) further comprising acquirer banks (105) through which said interbanking network (104) transmits and receives electronic data (B), wherein the activities of said acquirer banks (105) comprise also those which are developed under their own responsibility by application centers (107) that transceives electronic data with a plurality of terminal managers (106), which operate as an electronic interface towards a plurality of payment terminals (108) that comprise ATM (109) or POS (1 10) susceptible of being used by a user (101) which is the owner of an electronic payment card (200); wherein
between said payment terminal (108) and each of said terminal managers (106) it is preliminary performed the mutual authentication through a two-level public key (PKI) structure with a third party trusted entity and for managing the digital certificates (CA (122)).
2. System according to claim 1 , wherein on said POS (1 10) there is at least one key of protection of messages of services (KSER), not used for performing a financial transaction, wherein said key is managed by the corresponding terminal manger authority (106) and an initial key (KIP) used for cyphering a PIN introduced online from said user (101 ), a key of cyphering of the AP operating a verification of the PIN online for transactions in a third magnetic trace of said electronic payment card and a key for protecting financial messages (KPOS) used for the cyphering of financial messages exchanged between the payment terminal (108) and the terminal manager (106).
System according to claim 1, characterized in that said payment terminal ( 108) releases an AP amount which is cyphered by means of a TDES cyphering algorithm with a fixed key.
System according to any of the claims 1-3, characterized in that said payment terminal (108) comprises means of generation of a data packet containing said PIN, wherein said means of generation are activated for both EMV contact and contactless transactions and in second trace, and wherein said payment terminal (108) uses the Format 0 which is defined in the ISO 9564 standard and encodes it with TDES encoding.
System according to any of the preceding claims, characterized in that said initial key (KIP) is in turn derived from an initial key (KMP) or master PIN key which is generated in a cyphering device or crypto device (404) which receives in input said KMP electronically and automatically selected in accordance with an identification index (KID) and a random number which is generated by a tampering-resistant device (402).
System according to any of the preceding claims, characterized in that said initial key (KIP) used for cyphering a PIN introduced online from said user (101) is generated by means of a couple of DES encoders (501, 502), each receiving in input said (KMP); in said couple of DES encoders (501 , 502), the first DES encoder (501) further receives in input a KID jj TRSM ID string and provides in output the first portion of the key (KIP), i.e. (KIP A), the second DES encoder (502), further receives in input the string (KID) j| (TRSM ID) inverted, and provides in output the second portion of key (KIP), i.e. (KIPB), and wherein the key (KIP) is therefore given by (KIP) = (KIP A |j KIPB).
System according to any of the preceding claims, characterized in that said payment terminal (108) is configured for generating a key of session cyphering (KCUR), wherein said key of session cyphering (KCUR) is generated by means of a TDES cyphering, and in detail wherein said payment terminal comprises a couple of DES encoders (601 , 602) wherein said key for protecting financial messages (KPOS) used for cyphering the financial messages exchanged between the payment terminal (108) and the terminal manager (106) is realized by means of said couple of DES encoders (601 , 602), wherein together with an identification code of the online operation that is transmitted on a second input of the first decoder (601) of said couple of DES decoders (601, 602); said first DES decoder (601) generates in output a first portion of the key of cyphering (K-CUR), i e. the portion KCURA, and wherein the same key (KPos) is put in input to a second DES encoder (602), which receives an identification code of the online operation and produces in output a second portion of the key of cyphering (KCU ), that is the portion (KCURB), and wherein said key of session cyphering (KCUR) derives from the sequencing of the first portion (KCURA) with said second portion (KCURB).
8. Electronic method of acquisition for transceiving banking data with a plurality of issuer bank (102) and the operative and authorization centers (103) associated thereto, through which said issuer banks (102) manage a plurality of issuing activities, wherein the issuer banks (102) receive and transmit electronic data with an interbanking network (104), that, through bank acquirers, transmits and receives electronic data (B), wherein the activities of said bank acquirers (105) comprise also those performed under their own responsibility by application centers ( 107) that perform operations of transceiving electronic data with a plurality of terminal managers (106), which operate as an electronic interface towards a plurality of payment terminals (108) that comprise ATM (109) or POS (1 0) susceptible of being used by a user (101) which is the owner of an electronic payment card (200); wherein
between said payment terminal (108) and each of said terminal managers (106) is preliminary performed the mutual authentication through a two-levels public key (PKI) structure with third party and trusted entity for managing digital certificates (CA ( 122)).
9. Method according to claim 8, wherein on said payment terminal (108) there is, at the end of the mutual authentication, at least one key of protection of messages of service (KSER) not used for performing a financial transaction, wherein said key is managed by the corresponding terminal managing authority (106) and an initial key (Kip) used for cyphering a PIN that is introduced in a step of introduction of the PEN on said payment terminal (108) by said user (101), a key of cyphering of the AP operating as an online verification of the PIN for transactions in a third magnetic trace of said electronic payment card and a key for protecting financial messages (KPOS) used for cyphering the financial messages exchanged between the payment terminal (108) and the terminal manager (106).
10. Method according to claim 9, characterized in that it comprises a step of release, by the payment terminal (108), of an AP amount cyphered by means of a fixed key TDES cyphering algorithm.
1 1. Method according to claim 10, characterized in that said payment terminal (108) performs a step of generation of a data packet containing said PIN, wherein said step of generation i s performed for both EMV contact and contactless transactions and in second trace, and wherein said payment terminal (108) uses the Format 0 defined in standard ISO 9564 and encodes it with a TDES encoding.
12. Method according to any of the preceding claims 9- 1 1 , characterized in that it comprises a step of derivation of said initial key (KIP) from an initial key (KMP) or master key PIN generated in a device of cyphering or crypto device (404) which receives in input said (KMP) electronically and automatically selected in accordance with an identification index (KID) and a random number generated by a tampering-resistant device (402).
13. Method according to any of the preceding claims 9-12, characterized in that it comprises a step of generation of said initial key (KIP) used for cyphering a PIN introduced online by said user (101) by means of a couple of DES encoders (501, 502), each receiving in input said (KMP); in said couple of DES encoders (501, 502), the first DES encoder (501) further receives in input a string KID j| TRSM ID and provides in output the first portion of the key (KIP), i.e. (KIP A), the second DES encoder (502), further receives in input the string (KID) jj TRSM ID inverted, and provides in output the second portion of key (KIP), i.e. (KIPB), and wherein the key (KIP) results therefore given by (KIP) = (KIP A II KIPB).
14. Method according to any one of the preceding claims, characterized in that said payment terminal (108) performs a step of generation of a key of session cyphering (KCIJR) wherein said key of session cyphering (KCUR) is generated by means of a cyphering TDES, and in detail wherein said payment terminal comprises a couple of DES encoders (601 , 602) wherein said key for protecting financial messages KPOS used for cyphering financial messages exchanged between the payment terminal (108) and the terminals manager (106) is realized by means of said couple of encoders DES (601 , 602), wherein together with an identification code of the online operation that is transmitted on a second input of the first decoder (601) of said couple of DES encoders (601, 602); said first DES decoder (601) generates in output a first portion of the key of cyphering (KCUR), that is the portion KCURA, and wherein the same KPOS key is further put in input to a second DES encoder (602), which receives an identification code of the online operation and produces in output a second portion of the key of cyphering (KCUR), that is the portion (KCURB), and wherein said key of session cyphering (KCUR) derives from sequencing the first portion (KCURA) with said second portion (KCURB).
PCT/IB2017/053762 2016-06-28 2017-06-23 Electronic system of acquisition for transceiving banking data WO2018002792A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ITUA2016A004703A ITUA20164703A1 (en) 2016-06-28 2016-06-28 ELECTRONIC ACQUISITION SYSTEM FOR THE TRANSMISSION OF BANKING DATA.
IT102016000066699 2016-06-28

Publications (1)

Publication Number Publication Date
WO2018002792A1 true WO2018002792A1 (en) 2018-01-04

Family

ID=57750417

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2017/053762 WO2018002792A1 (en) 2016-06-28 2017-06-23 Electronic system of acquisition for transceiving banking data

Country Status (2)

Country Link
IT (1) ITUA20164703A1 (en)
WO (1) WO2018002792A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2713873C1 (en) * 2019-10-01 2020-02-07 Общество с ограниченной ответственностью "ЭВОТОР" System for remote loading of a set of keys into a smart terminal
US11562351B2 (en) * 2019-08-09 2023-01-24 Its, Inc. Interoperable mobile-initiated transactions with dynamic authentication

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1296259A1 (en) * 2001-09-25 2003-03-26 GTP Holding S.p.A. Advanced system for managing electronic financial transactions
US6705517B1 (en) * 1996-11-27 2004-03-16 Die Old, Incorporated Automated banking machine system and method
NZ563922A (en) * 2007-11-30 2010-07-30 Paymark Ltd Payment system
US20150046340A1 (en) * 2013-08-06 2015-02-12 James Dene Dimmick Variable authentication process and system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6705517B1 (en) * 1996-11-27 2004-03-16 Die Old, Incorporated Automated banking machine system and method
EP1296259A1 (en) * 2001-09-25 2003-03-26 GTP Holding S.p.A. Advanced system for managing electronic financial transactions
NZ563922A (en) * 2007-11-30 2010-07-30 Paymark Ltd Payment system
US20150046340A1 (en) * 2013-08-06 2015-02-12 James Dene Dimmick Variable authentication process and system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11562351B2 (en) * 2019-08-09 2023-01-24 Its, Inc. Interoperable mobile-initiated transactions with dynamic authentication
US12008554B2 (en) 2019-08-09 2024-06-11 Its, Inc. Interoperable mobile-initiated transactions with dynamic authentication
RU2713873C1 (en) * 2019-10-01 2020-02-07 Общество с ограниченной ответственностью "ЭВОТОР" System for remote loading of a set of keys into a smart terminal

Also Published As

Publication number Publication date
ITUA20164703A1 (en) 2017-12-28

Similar Documents

Publication Publication Date Title
KR102477453B1 (en) Transaction messaging
US8769275B2 (en) Batch settlement transactions system and method
CN103729940B (en) A kind of main cipher key T MK method for safely downloading of terminal and system
US9123042B2 (en) Pin block replacement
CN105052072A (en) Remote authentication and transaction signatures
CN104094302A (en) Data protection with translation
CN106465112A (en) Offline authentication
CN105684346A (en) Method for securing over-the-air communication between a mobile application and a gateway
CZ11597A3 (en) Method of safe use of digital designation in a commercial coding system
JPH10327147A (en) Electronic authenticating and notarizing method and its system
CN101216923A (en) A system and method to enhance the data security of e-bank dealings
CN102696047A (en) Encryption switch processing
CN101535845A (en) Authenticated radio frequency identification and key distribution system therefor
US20230103038A1 (en) Method for directly transferring electronic coin data sets between terminals, payment system, currency system and monitoring unit
US20100027786A1 (en) Dynamic encryption authentication
Omura Novel applications of cryptography in digital communications
CN104838398A (en) System and method for secure remote access and remote payment using a mobile device and a powered display card
CN104871186A (en) Application system for mobile payment and method for providing and using mobile means for payment
CN105162607A (en) Authentication method and system of payment bill voucher
US20230259899A1 (en) Method, participant unit, transaction register and payment system for managing transaction data sets
WO2018002792A1 (en) Electronic system of acquisition for transceiving banking data
WO2011069325A1 (en) Method for verifying validity of personal identification number in proxy authorization business
CN111630541B (en) Method and system for trusted notification
Park et al. OPERA: A Complete Offline and Anonymous Digital Cash Transaction System with a One-Time Readable Memory
KR20230004042A (en) An apparatus for providing payment services of a distributed token for encrypted data of payment information to be used only by a specific franchisee and a method for operating it

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17751830

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17751830

Country of ref document: EP

Kind code of ref document: A1