WO2013038417A1 - Procédé et système permettant de sécuriser des données sur un instrument de transaction financière - Google Patents

Procédé et système permettant de sécuriser des données sur un instrument de transaction financière Download PDF

Info

Publication number
WO2013038417A1
WO2013038417A1 PCT/IN2011/000632 IN2011000632W WO2013038417A1 WO 2013038417 A1 WO2013038417 A1 WO 2013038417A1 IN 2011000632 W IN2011000632 W IN 2011000632W WO 2013038417 A1 WO2013038417 A1 WO 2013038417A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
entity
instrument
authorized
identification data
Prior art date
Application number
PCT/IN2011/000632
Other languages
English (en)
Inventor
Gautam Bandyopadhyay
Kiran KANNAMBADI SUBBAKRISHNA RAMSESH
Original Assignee
Infosys Limited
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 Infosys Limited filed Critical Infosys Limited
Priority to PCT/IN2011/000632 priority Critical patent/WO2013038417A1/fr
Priority to AP2014007449A priority patent/AP3963A/en
Priority to SG2014010821A priority patent/SG2014010821A/en
Publication of WO2013038417A1 publication Critical patent/WO2013038417A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card

Definitions

  • the present invention relates generally to the data security of a multi-functional personal data security device.
  • the present invention relates to a method and system for securing data of multiple applications associated with multiple entities on a single financial transaction instrument by a dynamic key generation mechanism.
  • a financial transaction instrument can alternatively be termed as a smart card, a memory card, an integrated circuit card, a memory card, a processor card or typically any plastic card that includes one or more semiconductor integrated circuits.
  • Issuance of a smart card requires an initialization process followed by a personalization process.
  • data and data structures that are common to a batch of smart cards are burned into the cards by a card manufacturer such as Gemalto, Oberthur, Philips, Samsung and the like. Instances of such data or data structures can include the serial number of the smart card, a master key of the smart card, currency of the applications to be hosted by the smart card and the like.
  • the personalization process follows, which includes, loading the smart card with user data that uniquely identifies the card as belonging to a particular user.
  • the personalization process can be performed in a manufacturing unit using specialized personalization equipment, alternatively known as a field device.
  • the smart card is issued to the user by mail or in person.
  • the personalization process takes place as an offline process in the manufacturing unit.
  • a delay is created in the issuance of the smart card, which is a deterrent to the user for applying for the smart card.
  • specialized personalization equipment is deployed, at a Point of Transaction (POT) terminal or at a customer touch-point that can inject user data into the smart card for instant issuance of the smart card to the user.
  • POT Point of Transaction
  • the specialized personalization equipments being expensive are a deterrent for wide spread deployment thereby raising the entry barrier for the users.
  • multi-application smart cards that can be used across various entities such as banks, hospitals, travel agencies, educational institutions and the like that offer multiple services to the users
  • the specialized equipment would have to be altered for the different types of smart cards issued and for the various services being offered.
  • Alteration of the specialized equipment for issuance of multi-application smart cards is a known to be a cumbersome, incompatible and expensive process.
  • the existing smart card models use firmware security tokens for securing data and transactions occurring through the smart card.
  • the firmware security tokens required for controlling access to the various applications and files on the smart card are stored on the network devices available for transaction with the smart cards; such as a card reader, a point of sale terminal or any other computing device, hereinafter referred to as a network device.
  • the firmware security tokens are known to be difficult to deploy and manage for reasons as stated herein. Firstly, though the firmware security tokens are stored in a cryptographic format on the network device, this layer of security has been known to be breached by brute-force methods, data-sniffing techniques, keyboard hooks, magnetic card duplicators, smart card emulators and so forth.
  • the network device represents a single point of attack for hackers to emulate the functionality of the network device during the authentication phase of the smart card. This poses a severe threat for financial transactions processed through such a fraudulent network device.
  • the permutations of unique firmware security tokens that can be deployed are reduced, thereby limiting the number of smart cards that can be supported.
  • each unique combination of the firmware security tokens is repeated for a bunch of smart cards the security of data on the smart cards gets compromised.
  • the essential drawback of the existing systems concerning the security on the smart cards is due to the use of static data which if obtained, can be used to commit fraud.
  • the proposed method describes a method and system wherein the user data is made dynamic in nature and can be instantly loaded on the smart card using a software application. As the user data can be written on the smart card at the customer touch-point or at the POT terminal, the smart card can be issued instantly. Further, the system deploys an inexpensive smart card read and write device thereby lowering the cost of issuance of the smart card and the entry barrier for the users. As a result of using dynamic security tokens, the security issues prevalent earlier at the network devices get resolved.
  • the present invention alleviates the above mentioned drawbacks of the existing prior art by providing a method and system for securing the data on a financial transaction instrument by generating a set of keys dynamically on a transaction terminal and loading the set of keys on the financial transaction instrument where the set of keys refer to a set of authorized keys when a user is an authorized user of the financial transaction instrument.
  • the instant invention provides a method for accessing a user identifier by a transaction terminal where the user identifier is associated with an authorized user and is stored on a financial transaction instrument, generating a set of authorized keys at the transaction terminal using the user identifier where the user identifier is commonly accessed by one or more entities that process transactions through the financial transaction instrument, partitioning the memory of the financial transaction instrument into a set of storage areas by the transaction terminal where each storage area is associated with one of the entities, and allocating the set of authorized keys to the set of storage areas where the set of authorized keys are adapted to perform operations on the data stored in the memory of the financial transaction instrument.
  • the instant invention also provides a system for securing data on a financial transaction instrument.
  • the system comprises a financial transaction instrument, comprising; a personal file section configured to store a user identifier associated with an authorized user; a key file section configured to store a master key and a set of authorized keys; and a transaction file section configured to store the data, and a transaction terminal associated with at least an entity that communicates with the financial transaction instrument for processing a transaction.
  • the transaction terminal comprises an interface module configured to provide access to the financial transaction instrument, a repository configured to store a list of instrument identifiers, a set of master keys and an entity identification data of the at least one entity, a key generation module configured to generate a set of keys, a personalization module configured to partition the transaction file section into a set of storage areas and allocate the set of authorized keys to each element of the set of storage areas, and a validation module configured to authenticate any user purporting to process the transaction using the financial transaction instrument.
  • FIG. 1 is a flowchart illustrating a method of securing data on a financial transaction instrument.
  • FIG. 2 is a flowchart illustrating a preferred embodiment of a method of securing data on the financial transaction instrument.
  • FIG. 3 is a flowchart illustrating a method of validating a user of the financial transaction instrument.
  • FIG. 4 is a flowchart illustrating a preferred embodiment of a method of validating a user of the financial transaction instrument.
  • FIG. 5 illustrates an exemplary system environment in which features of the present invention can be practiced.
  • the present invention is applicable to financial transaction instruments 502(refer FIG. 5), also termed as but not limited to smart cards, chip cards, integrated circuit cards, memory cards, or processor cards.
  • a method and system for instant issuance of smart cards using an inexpensive read or write transaction terminal for bringing down the entry barrier for users is illustrated herein below.
  • the system includes software driven security infrastructure management system to provide a transaction terminal 512(ref FIG. 5) that can issue the smart cards instantly in an inexpensive manner. Further, the software driven security infrastructure management system, provides a dynamic key generation process for validating a user purporting to perform a transaction through the smart card.
  • Basic components of the system that are preferably required for practicing an embodiment of the present invention are a card manufacturer, a card issuer that undertakes the functionality of issuing the smart card instantly at the transaction terminal 512, and the transaction terminal 512 that is preferably the point of contact for the user on the field and the financial transaction instrument 512.
  • the transaction terminal 512 can be any suitable terminal such as are known in the art for reading from and writing to, financial transaction instrument, smart cards, integrated circuit cards, chip cards and the like.
  • the transaction terminal 512 can be any suitable interface device that can transfer information and commands between the financial transaction instrument 512 and the user or a computing device. Further, the transaction terminal 512 can include a processor, application software, and the ability to communicate over a network.
  • the transaction terminal 512 can take a variety of physical forms such as; a standalone unit integrated with a computer and a keyboard of the computer or it can be built into a memory disk that is capable of being read from; a disk drive of a computer; or a portable device such as a laptop, a cellular phone or a personal digital assistant (PDA).
  • the transaction terminal 512 are alternatively also termed as but not limited to an interface device (IFD), a chip-accepting device (CAD), a chip card reader (CCR), a smart card adapter and a card reader device.
  • IFD interface device
  • CAD chip-accepting device
  • CCR chip card reader
  • smart card adapter a smart card adapter
  • the card manufacturer is responsible for manufacturing the financial transaction instrument 502. Instances of card manufacturers are Gemalto, Oberthur, Philips, Samsung and the like.
  • the card issuer may be an entity such as a bank, a financial institution, a service association, a merchant, or any other organization or agent acting on behalf of such organization.
  • the card issuer hereinafter referred to as the entity, deploys the transaction terminal 512in a field for interacting with the users and for issuing the financial transaction instruments to the users.
  • An entity identification data is usually stored on the transaction terminal 512.
  • the entity identification data is used during processing of the transactions initiated by the financial transaction instrument 502.
  • the entity identification data can be a bank identification number or a bank code when the entity is preferably a bank.
  • the smart card can be a blank card such as a Smart Card Operating System for Transport Application (SCOSTA), a MiFare card or aDESFire8 card.
  • An open platform smart card is recommended for performing the present invention, as applications can be added to such a smart card post-issuance for making the smart card multi-purpose in nature.
  • the Open Platform smart card is capable of including multiple ownership by various entities and running the various applications offered by each such entity.
  • the issuance of the smart card undergoes certain basic steps such as initialization, personalization and loading of application codes required for running applications provided by the entities.
  • the initialization process is usually carried out by the card manufacturer.
  • data and data structures that are common to a set of smart cards are installed on the financial transaction instrument 502.
  • An instance of the data that can be common to a set of smart cards is a master key.
  • Post initialization a set of master keys associated with the set of smart cards generated by each card manufacturer are distributed by an authentic Key Management Authority (KMA) to the various entities that seek to transact with the financial transaction instrument 502.
  • KMA Key Management Authority
  • the KMA can be a special kind of Certification Authority that controls the distribution of the set of master keys amongst the entities that intend to be associated with the financial transaction instrument 502.
  • the entities can retrieve and verify an authenticity certificate of an individual financial transaction instrument card, and encrypt their proprietary application code and confidential personalization data using that financial transaction instrument's master key.
  • the set of master keys distributed to one entity are kept confidential with the KMA.
  • a personalization process follows, which may be performed by the card manufacturer for the set of smart cards that are to be used for a specific purpose, or individually by the entity.
  • the smart card is preferably loaded with data that uniquely identifies the user of the financial transaction instrument 502.
  • the personalization data can include a user identifier, a personal identification number of the user, a social security number of the user and a biometric identification data of the user and a set of authorized keys.
  • the user identifier can be a unique identification code that uniquely identifies the user.
  • the user identifier can be utilized by the transaction terminal 512 to generate the set of authorized keys.
  • the biometric identification data can include the fingerprint details of the user, the iris scan details, the blood identification data and the like.
  • a personalization equipment alternatively referred to as a personalization module 520 (refer FIG. 5), is disposed at the transaction terminal 512 for the personalization process. After the personalization process, entity identification data and application codes associated with applications required by the entity for processing transactions on the smart card are loaded on the smart card by the personalization module 520.
  • the entity identification data can be a unique entity identification code associated with the entity. Post loading of the personalization data and the application codes on the smart card, the smart card is issued to the user or distributed to the user
  • FIG. 1 illustrates the basic steps performed by the system for securing data on the financial transaction instrument during the personalization process.
  • the transaction terminal 512 accesses the user identifier stored on the financial transaction instrument 502.
  • the user identifier is usually associated with an authorized user of the financial transaction instrument 502.
  • the authorized user is basically the user in whose name the financial transaction instrument has been issued.
  • the transaction terminal 512 uses the user identifier to generate the set of authorized keys.
  • the user identifier is usually a data that can be commonly accessed by all the entities that communicate with the financial transaction instrument 502.
  • the user identifier signifies the access point or the entry point to the data that is stored on the financial transaction instrument 502.
  • the user identifier can be accessed only when the authorized user purports to use the financial transaction instrument for the transaction.
  • a memory structure on the financial transaction instrument is partitioned into separate storage areas or memory cells, each storage area being associated with one of the entities that can communicate with the financial transaction instrument 502.
  • the transaction terminal 512 associated with the bank shall make a partition from the memory structure to store the data associated with the transaction to be carried out in association with the bank.
  • the data can include the personalization data, customer personal details of the user required for registration with the bank, the entity identification data of the bank such as the bank code, and data associated with the transaction.
  • the personalization data can be stored in a personal file section 504 (refer FIG.
  • the customer personal details can include customer name as it appears on bank records, customer address, customer city, customer state, customer country, status, customer date of birth, ration card number, driver's license number, voter ID number, national ID, account number, account name, account type, product type, account currency, account balance, account status, and any other customer update data.
  • the entity identification code, the customer details and the data associated with the transaction can be stored in the transaction file section 508 (refer FIG. 5) of the financial transaction instrument 502.
  • the set of authorized keys are stored in an area allocated for the entity in the key file section 506 (refer FIG. 5) of the financial transaction instrument 502.
  • the set of authorized keys are allocated to the storage area partitioned by the transaction terminal 512 for the entity.
  • the set of authorized keys are configured to perform a plurality of operations on the data stored in the transaction file section 508 such as delete, read , write, modify, update and the like.
  • FIG. 2 illustrates a preferred embodiment of securing data on the financial transaction instrument during the personalization process.
  • the financial transaction instrument bears a instrument identifier which is read by a card reader interface of the transaction terminal 512 at step 202.
  • the card reader interface includes any of the conventionally known software and hardware, necessary for communication with devices external to the transaction terminal 512.
  • the transaction identifier can be a serial identification number of the smart card, the serial identification number being hardware encoded into the smart card during manufacturing process of the card.
  • the instrument identifier read from the financial transaction instrument is matched to a instrument identifier that is preferably stored in a card manufacturer record 516a (refer FIG. 5) of a repository 516(refer FIG.
  • the card manufacturer record 516a may include the instrument identifier of the financial transaction instrument and the master key associated with the financial transaction instrument, the master key required for gaining access to the financial transaction instrument 502.
  • the master key stored across the instrument identifier that matches to the instrument identifier of the financial transaction instrument 502, in the card manufacturer record 516a, is retrieved by an interface module 514 (refer FIG. 5), disposed within the transaction terminal 512.
  • the master key is used by the interface module 514 to gain access to the user identifier 504a (refer FIG. 5) of the financial transaction instrument 502 at step 206.
  • the user identifier 504a is used by the transaction terminal 512 to read the personal identification data of the user stored in the personal file section 504(refer FIG. 5) of the financial transaction instrument 502.
  • the personal identification data of the user can include, a personal identification number (PIN), a social security number such as a National ID, and a biometric identification data.
  • the biometric identification data can include fingerprint data, iris scan data, blood group, and the like.
  • the transaction terminal 512 retrieves the entity identification data stored at a storage area 532 in the repository 516 of the transaction terminal 512 at step 208.
  • the entity identification data, the personal identification data and the user identifier are used as inputs to a unique function, provided by the entity, for computing the set of authorized keys for the user.
  • the unique function could be a random function logic that can be determined by the entity and stored fed into the memory of the key generation module 518 (refer FIG. 5) of the transaction terminal 512.
  • Kl ⁇ (the user identifier, the PIN , numeral 5)
  • Kl stands for summation of parameters following
  • Kl stands for the key to be used for reading data.
  • the memory structure in the key file section 506 is partitioned by the transaction terminal 512 to store the set of authorized keys (step 214) and the memory area of the transaction file section 508 is further partitioned to secure one or more storage area for storing the data associated with the transaction, and details of the user in specific relationship with the entity (step 220).
  • the set of authorized keys are allocated to the one or more storage areas at step 218.
  • the set of authorized keys are configured to perform a plurality of operations on the data stored in the transaction file section 508 such as delete, read , write, modify, update and the like.
  • the authentication of the personal details of the user as required for populating the transaction file section 508 can be processed by any of the conventionally known methods and processes.
  • the use of software-driven logic for generating the set of authorized keys aids in the instant issuance of the financial transaction instrument 502 instantly. Consequently, the entry barrier for the users, that otherwise existed the prior systems of issuing financial transaction instruments, is minimized to a considerable extent.
  • FIG. 3 illustrates the essential steps required in the method for validating a user of the financial transaction instrument, the user being any user purporting to use the financial transaction instrument for the transaction.
  • the user is the authorized user of the financial transaction instrument
  • access to perform the transaction shall be given to the user, however, in the event the user is a fraudulent user the access shall be denied.
  • the user identifier 504a stored in the personal file section 504 of the financial transaction instrument 502 is accessed by the transaction terminal 512 when the financial transaction instrument 502 is brought in connection to the card reader interface of the transaction terminal 512.
  • the user identifier is explained to be associated with the authorized user of the financial transaction instrument.
  • a set of keys are generated using the user identifier 504a, personal details of the user and entity identification data stored in 532 of the repository 516 of the transaction terminal.
  • the set of keys are generated by the unique function fed into the key generation module 518, by the entity.
  • the unique function used to generate the set of keys is the same as used to generate the set of authorized keys during the personalization process, the set of keys generated must match the set of authorized keys for a valid user.
  • the transaction terminal reads the set of authorized keys associated with the authorized user, from the key file section 506, of the financial transaction instrument 502.
  • the set of keys are compared to the set of authorized keys to conclude if the user is the authorized user. In the event the set of keys differ from the set of authorized keys, the user is denied access to perform the transaction through the financial transaction instrument. However, in the event the set of keys match the set of authorized keys the user is authenticated as the authorized user and is given access to perform the transaction.
  • FIG. 4 illustrates a preferred embodiment of a method for validating a user of the financial transaction instrument 502.
  • the transaction terminal 512 reads the instrument identifier of the financial transaction instrument 502.
  • the instrument identifier read from the financial transaction instrument 502 is preferably matched to an instrument identifier that may be stored in a card manufacturer record 516a of the repository 516 on the transaction terminal 512.
  • the card manufacturer record 516a may include the instrument identifier of the financial transaction instrument and the master key associated with the financial transaction instrument, the master key required for gaining access to the financial transaction instrument 502.
  • the master key stored across the instrument identifier that matches to the instrument identifier of the financial transaction instrument 502, in the card manufacturer record 516a, is retrieved by the interface module 514, disposed within the transaction terminal 512.
  • the master key is used by the interface module 514 to gain access to the user identifier 504a of the financial transaction instrument 502 at step 406.
  • personal identification data of the user is captured by an input module 524 (refer FIG. 5) at the transaction terminal 512.
  • the input module can comprise of a standard keyboard, a scanning machine, a camera and other devices that can capture data of the user.
  • the personal identification data of the user can include, a personal identification number (PIN), a social security number such as a National ID, and a biometric identification data.
  • the biometric identification data can include fingerprint data, iris scan data, blood group, and the like. Nature of the personal identification data captured by the user shall be similar to that as captured of the authorized user during the personalization process for generation of the set of authorized keys.
  • the transaction terminal 512 retrieves the entity identification data stored at 532 in the repository 516 of the transaction terminal 512 at step 410. Further at step 412, the entity identification data, the personal identification data of the user and the user identifier are used as inputs to the set of unique function for generating the set of keys.
  • the unique function used to generate the set of keys is the same function as used to generate the authorized set of keys.
  • the set of unique functions is stored in the key generation module 518 of the transaction terminal 512.
  • the set of keys generated at the transaction terminal 512 are compared to the set of authorized keys read from the key file section 506, at step 414.
  • the user is authenticated as the authorized user of the financial transaction instrument 502, at step 418, and is provided access to perform one or more transactions, step 420.
  • the set of keys generated do not match the set of authorized keys the user is denied access to the financial transaction instrument, step 416.
  • the security of the financial transaction instrument is protected from being breached by a fraudulent user whose personal identification data do not match with those of the authorized user as stored in the personal file section 504.
  • the need for storing the set of authorized keys on the transaction terminal is eliminated. Dynamic generation of keys at the time of validation of the user provides the essential security required for financial transaction instruments. Further the only data that needs to be stored on the transaction terminal is the master key associated to the financial transaction instrument. A single master key can be used to generate a large number of keys using different set of unique functions. As a result, a large number of financial transaction instruments, each having a unique set of keys, can be supported by the same master key. The necessary consequence of using the unique set of functions to generate the set of keys dynamically is the memory limitation of the transaction terminals is overcome as a large number of financial transaction instruments having a unique set of keys can be processed through the same transaction terminal using the same master key.
  • Fig. 5 illustrates an environment in which various embodiments of invention can be practiced.
  • the environment 500 includes the user 528, the financial transaction instrument 502, and the transaction terminal 512.
  • the financial transaction instrument 502 includes a memory structure 530, which further includes a personal file section 504, a key file section 506 and a transaction file section 508.
  • the personal file section is configured to store the user identifier 504a and the personal identification data of the authorized user.
  • the key file section 506 comprises a set of separate storage areas for storing the set of authorized keys of the authorized user. For instance, the set of authorized keys in association with the entity can be stored in a separate storage area 506a.
  • the transaction file section 508 stores the data associated with the transaction carried out by the financial transaction instrument 502 in communication with the transaction terminal 512.
  • the data includes the user personal details as required by the transaction terminal 512 for processing the transaction, the entity identification data of the entity associated with the transaction terminal 512 and other transaction details.
  • the transaction terminal 512 includes the repository 516, the interface module 514, a personalization module 520, a validation module 522, the key generation module 518, the input module 524 and an output module 526.
  • the repository 516 can be a suitable database file as known in the art for containing a set of card manufacturer records.
  • a card manufacturer record 516a can include the instrument identifier of the financial transaction instrument 502 and the master key used to access the financial transaction instrument 502.
  • the repository can be configured to store a set of entity identification data at a storage area 531 of the repository 516, each entity identification data shall be associated with the entity that can communicate with the financial transaction instrument 502 through the transaction terminal 512.
  • the interface module 514 provides the necessary interface required for initiating communication with the financial transaction instrument 502.
  • the interface module can include a card reader interface for reading the instrument identifier stored on the financial transaction instrument 502, when the financial transaction instrument 502 is brought in contact with the transaction terminal for the purpose of processing the transaction.
  • a card reader interface for reading the instrument identifier stored on the financial transaction instrument 502, when the financial transaction instrument 502 is brought in contact with the transaction terminal for the purpose of processing the transaction.
  • a wide variety of card reader interfaces as conventionally known can be employed within the interface module 514 for communication with the financial transaction instrument 502.
  • the interface may provide a contact interface, a remote- coupled interface, or a variety of other interfaces.
  • signals from an integrated circuit disposed at the financial transaction instrument 502 are routed via metal contacts to the outside of the financial transaction instrument 502, which then come in contact with similar contacts present on the card reader interface.
  • Other interfaces include wireless transmission of signals from the financial transaction instrument 502 to the card reader interface of the interface module 514.
  • the interface module can use electrical connections embedded within the transaction terminal 512, to read a set of card manufacturer records 516a, 516b up to 516n, from the repository 514. Subsequently, the interface module 514 shall use comparison logic to search the instrument identifier read from the financial transaction instrument 502 within the list of instrument identifiers existing in the set of card manufacturer records, 516a, 516b up to 516n read from the repository 514. In the event the instrument identifier is found in the set of card manufacturer records, 516a, 516b up to 516n, it signifies that the transaction terminal 512 is equipped with the necessary application required for processing the transaction.
  • the financial transaction instrument shall be denied access to perform the transaction through the transaction terminal and the transaction terminal shall be denied access to the financial transaction instrument.
  • the master key stored against the instrument identifier in the list of instrument identifiers is retrieved.
  • the master key is the access code to the financial transaction instrument 512.
  • the master key can be provided to the operating system of the financial transaction instrument 502 to retrieve the user identifier of the authorized user.
  • the user identifier can be stored in a storage area 514a of the personal file section 504.
  • the user identifier can include a personal identification data or a unique identification number of the authorized user.
  • the interface module 514 provides the master key to the operating system of the financial transaction instrument 502, and receives the user identifier in response.
  • the personalization module 520 uses the retrieved user identifier for the personalization process of the financial transaction instrument.
  • the personalization process involves, generating the set of authorized keys and storing the personal identification data of the authorized user in the personal file section.
  • the personalization module 520 reads the key inputs required for generation of the set of authorized keys.
  • the key inputs can include the user identifier as read from the interface module 514, the entity identification data read from the storage area 532 of the repository 516, and the personal identification data of the authorized user as received by the input module 524.
  • the input module 524 can be any device suitable for receiving data that is inserted or provided by the user.
  • the input module 524 can include a keyboard, a touch screen, a scanning machine, or any other data sensing device.
  • the input module 524 can be enabled with bio-metric authentication for benefitting the illiterate.
  • the bio-metric authentication can also be used for authenticating a field agent who operates the transaction terminal thereby improving the security of the financial transaction instrument transactions.
  • the key generation module 518 is designed computes the value of the set of unique functions when the key inputs are provided.
  • the set of unique functions are defined by the entity. Value of the set of unique functions comprises the set of authorized keys which are stored by the personalization module 520 into a key storage area 506a of the key file section 506.
  • the key storage area 506a represents the area where the set of authorized keys associated with the particular entity are stored.
  • the set of authorized keys of different entities shall be stored in separate storage areas such as 506a, 506b, 506c, up to 506n.
  • Each key of the set of authorized keys are configured by the key generation module 518 to perform various operations such as add, modify, delete, read, write, and update data in the personal file section 504 and the transaction file section 508 of the financial transaction instrument 512.
  • the personalization module 520 is designed to partition the transaction file section into one or more storage areas. Each of the storage area can store the data associated with the transactions associated with various entities and applications. The criteria of partitioning the transaction file and the manner in which data would be stored in the transaction file section can be set as per techniques conventionally known. On partitioning the transaction file, the personalization module 520 defines which of the set of authorized keys shall hold the access and modification permissions to the partitioned storage area.
  • authorizing the user for performing the transaction using the financial transaction instrument 502 is carried out by the validation module 522.
  • the validation module 522 receives the key inputs such as the personal identification data of the user from the input module 524, the entity identification data as stored in 532 and the user identifier from the interface module 514. Further the validation module provides the key inputs to the key generation module 518.
  • the key generation module 518 generates the set of keys in response to the key inputs provided.
  • the set of keys are generated using the same set of unique functions as used during the personalization process, and hence if the user is the authorized user the set of keys ought to match with the set of keys stored in the personal file section 506.
  • the validation module In order to compare the set of keys to the set of authorized keys the validation module reads the set of authorized keys from the key storage area 506a of the personal file section 506 and provides the set of keys and the set of authorized keys to a comparator function logic. In the event the set of keys are similar to the set of authorized keys, the comparator function logic outputs a positive response signifying that the user is the authorized user. On receiving the positive response the validation module 522, provides access to the user for performing the transaction. However, in the event the set of keys differ from the set of authorized keys, the comparator function logic outputs a negative response, indicating that the user is a fraudulent user and ought not to be given access to perform the transaction.
  • an authentication failure message is composed by the validation module 522 and sent to the output module 526 for displaying it to the user.
  • the output module 526 can include any suitable device that can display messages such as a computer screen, an LED display, a LCD or any display of the portable device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé et un système permettant de sécuriser des données sur un instrument de transaction financière en accédant à une donnée d'identification unique d'un utilisateur au moyen d'un terminal de transaction, de générer un ensemble de clés autorisées au moyen de la donnée d'identification unique de l'utilisateur dans le terminal de transaction, de partitionner une structure de mémoire de l'instrument de transaction financière en un ensemble de zones d'enregistrement de façon à associer chaque zone d'enregistrement à une entité avec laquelle l'utilisateur effectue une transaction au moyen de l'instrument de transaction financière, et d'attribuer l'ensemble de clés autorisées à l'ensemble de zones d'enregistrement pour effectuer une pluralité d'opérations sur les données enregistrées dans l'ensemble de zones d'enregistrement. La génération dynamique de clés dans le terminal de transaction aboutit à l'émission instantanée de l'instrument de transaction financière.
PCT/IN2011/000632 2011-09-14 2011-09-14 Procédé et système permettant de sécuriser des données sur un instrument de transaction financière WO2013038417A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/IN2011/000632 WO2013038417A1 (fr) 2011-09-14 2011-09-14 Procédé et système permettant de sécuriser des données sur un instrument de transaction financière
AP2014007449A AP3963A (en) 2011-09-14 2011-09-14 A method and system for securing data on a financial transaction instrument
SG2014010821A SG2014010821A (en) 2011-09-14 2011-09-14 A method and system for securing data on a financial transaction instrument

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2011/000632 WO2013038417A1 (fr) 2011-09-14 2011-09-14 Procédé et système permettant de sécuriser des données sur un instrument de transaction financière

Publications (1)

Publication Number Publication Date
WO2013038417A1 true WO2013038417A1 (fr) 2013-03-21

Family

ID=47882708

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2011/000632 WO2013038417A1 (fr) 2011-09-14 2011-09-14 Procédé et système permettant de sécuriser des données sur un instrument de transaction financière

Country Status (3)

Country Link
AP (1) AP3963A (fr)
SG (1) SG2014010821A (fr)
WO (1) WO2013038417A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108197690A (zh) * 2017-12-28 2018-06-22 金邦达有限公司 支付卡、开票系统及开票方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577121A (en) * 1994-06-09 1996-11-19 Electronic Payment Services, Inc. Transaction system for integrated circuit cards
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US20070152068A1 (en) * 2004-01-06 2007-07-05 Taro Kurita Data communicating apparatus and method for managing memory of data communicating apparatus

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5889941A (en) * 1996-04-15 1999-03-30 Ubiq Inc. System and apparatus for smart card personalization
AU755458B2 (en) * 1997-10-14 2002-12-12 Visa International Service Association Personalization of smart cards
US6729549B2 (en) * 2000-12-19 2004-05-04 International Business Machines Corporation System and method for personalization of smart cards

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577121A (en) * 1994-06-09 1996-11-19 Electronic Payment Services, Inc. Transaction system for integrated circuit cards
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US20070152068A1 (en) * 2004-01-06 2007-07-05 Taro Kurita Data communicating apparatus and method for managing memory of data communicating apparatus

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108197690A (zh) * 2017-12-28 2018-06-22 金邦达有限公司 支付卡、开票系统及开票方法

Also Published As

Publication number Publication date
AP3963A (en) 2016-12-24
SG2014010821A (en) 2014-06-27
AP2014007449A0 (en) 2014-02-28

Similar Documents

Publication Publication Date Title
CN106576044B (zh) 泛在环境中的认证
US8458484B2 (en) Password generator
JP4578244B2 (ja) 携帯型データ記憶媒体を使って安全な電子取引を実行する方法
US20080249947A1 (en) Multi-factor authentication using a one time password
US20100095130A1 (en) Smartcards for secure transaction systems
EP3681126B1 (fr) Systèmes et procédés de vérification sécurisée d'un sous-ensemble d'informations personnellement identifiables
WO2010045235A1 (fr) Systèmes et procédés de transaction sécurisée faisant appel à une carte à puce intelligente
JP2000215172A (ja) 個人認証システム
CN1959750B (zh) 现金自动存取系统及装置
EP1625548A1 (fr) Carte d'authentification intelligente
WO2020001456A1 (fr) Procédé de dissimulation d'informations de confidentialité de carte bancaire, carte bancaire et support de stockage lisible par ordinateur
WO2015004803A1 (fr) Dispositif terminal de paiement et système de paiement
TW202040385A (zh) 以裝置識別資料透過電信伺服器識別身份之系統及方法
CN112669021B (zh) 一种基于移动终端的数字货币硬件钱包
JP2001525088A (ja) インテリジェント・データキャリヤのデータの安全な読み取りおよび処理のためのシステム
US20150007300A1 (en) Method, apparatus, and system for using ic card as authentication medium
WO2023130862A1 (fr) Dispositif terminal de gestion d'actifs numériques et procédé de gestion d'actifs numériques
JP2007072777A (ja) 取引処理システム
TWM580206U (zh) System for identifying identity through device identification by device identification data
WO2013038417A1 (fr) Procédé et système permettant de sécuriser des données sur un instrument de transaction financière
JP2007115058A (ja) 自動取引装置
US20230245125A1 (en) Identity verification using a virtual credential
JP2002041813A (ja) 個人認証システム
US11893587B2 (en) System for enhanced authentication using non-fungible tokens (NFTs)
JPS63263848A (ja) 認証方式

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: 11872284

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: P132/2014

Country of ref document: AE

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11872284

Country of ref document: EP

Kind code of ref document: A1