EP0593244A2 - Secure IC card system with reusable prototype card - Google Patents
Secure IC card system with reusable prototype card Download PDFInfo
- Publication number
- EP0593244A2 EP0593244A2 EP93308087A EP93308087A EP0593244A2 EP 0593244 A2 EP0593244 A2 EP 0593244A2 EP 93308087 A EP93308087 A EP 93308087A EP 93308087 A EP93308087 A EP 93308087A EP 0593244 A2 EP0593244 A2 EP 0593244A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- card
- password
- prototype
- cards
- issuer
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- 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/22—Payment schemes or models
- G06Q20/229—Hierarchy of users of accounts
-
- 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- 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/355—Personalisation of cards for use
Definitions
- This invention relates to an IC card system such as a bank card system, more particularly to an IC card system that is secure, yet can be developed without spoiling a large number of cards.
- Wallet-size cards similar in appearance to ordinary credit cards but having embedded integrated circuits (ICs), are issued by institutions such as banks as a convenient means of managing financial and other data.
- IC cards Popularly known as “smart cards,” these cards will be referred to herein as IC cards.
- An IC card system comprises not only the IC cards themselves but also various software.
- the software includes, for example, an issuing program used in issuing the cards to end users, and application programs used to process the cards when they are inserted in card-handling devices such as automatic teller machines.
- a feature of IC card systems is that they can be made extremely secure by protecting the cards with passwords, and by protecting certain data in the cards from alteration even by a person who knows the password.
- the cards are manufactured by one entity (the card manufacturer), then issued by another entity (the card issuer) to end users.
- the card manufacturer programs the cards with a manufacturer's password known only to the card manufacturer and card issuer.
- the card issuer changes the password to an issuer's password known only to the card issuer, stores certain issuer data and application data in the card, and sets protection bits that permanently prevent some of these data from being altered.
- the card issuer issues the card to an end user, he stores further information in the card, such as the user's name, address, and personal identity number. Some of this information may also be permanently protected from alteration.
- An end user cannot tamper with the data in his card because he does not know the issuer's password. If the card is stolen by a third party, that party cannot tamper with the card for the same reason. If the third party steals a card from the card manufacturer, he still cannot tamper with it because he does not know the manufacturer's password. The card manufacturer himself is unable to tamper with a card once the card issuer has changed the password. Furthermore, even if someone who knew the issuer's password were to use it to gain unauthorized access to an already-issued card, he would be unable to reissue the card to himself because of the permanent protection of data in the card. In this way an IC card can be made secure against virtually any kind of attack, whether it be by an end user, a third party, the card manufacturer, or an employee of the card-issuing institution.
- a disadvantage of these security arrangements is that the card issuer is forced to expend a large number of cards in the process of developing and debugging his software. This is particularly true when the software is developed through a trial-and- error process, which is often the case.
- a card issuer who is developing an issuing program He completes a first version of the program and tests it by issuing a first card to an imaginary end user. The card is then evaluated by checking that it contains correct data and works correctly with application software. If any deficiencies are found, the issuing program is modified, and the modified program is tested by issuing a second card. Even if no problems are found, additional cards are issued to test the program under different sets of issuing conditions.
- Another object of the invention is to maintain existing levels of security.
- the invented IC card system uses a set of IC cards comprising a prototype card and one or more production cards.
- the prototype card is programmed to execute a standard set of commands for reading and writing data in the card, and an initialize command for initializing these data.
- the software can be tested by repeatedly issuing, initializing, and reissuing the prototype card.
- Production cards are programmed to execute the same standard set of commands, and a version read command.
- the version read command reads out a version number distinguishing a production card from the prototype card.
- Production cards are not programmed to execute the initialize command.
- Production cards are personalized with end user data and distributed to end users.
- Fig. 1 is a block diagram of an integrated circuit that may be used in the invented IC card system.
- the circuit comprises a central processing unit (CPU) 1, an interface 2, a mask-programmable read-only memory (mask ROM) 3, a non-volatile data memory 4, and a volatile random-access memory (RAM) 5.
- the interface 2 enables the CPU 1 to communicate with an external card-handling device such as an automatic teller machine.
- the data memory 4 comprises, for example, so-called flash memory, orelectrical- ly-erasable programmable read-only memory (EE-PROM).
- the RAM 5 is used as a work area during program execution.
- the circuit blocks in Fig. 1 are well known to those skilled in the art, so detailed descriptions will be omitted.
- IC cards containing the integrated circuit in Fig. 1 are supplied from a card manufacturer to a card issuer, who then issues them to end users.
- the card manufacturer may manufacture the integrated circuit himself, or he may obtain it from an IC manufacturer. In either case, the card manufacturer programs the mask ROM 3, e.g. by supplying the IC manufacturer with mask data. Once the IC is manufactured, it is physically impossible to alterthe contents of the mask ROM 3. The contents of the data memory 4, in contrast, can be altered.
- the data memory 4 is programmed by both the card manufacturer and card issuer.
- Fig. 2 illustrates two types of IC cards in various stages of programming, indicating the contents of their mask-programmable ROM 3 and data memory 4.
- One of these types illustrated at the top of Fig. 2, is a prototype card used by the card issuer during program development.
- the other type, illustrated at the bottom of Fig. 2 is a production card, which is distributed to end users.
- the mask ROM 3 of a blank prototype card 7 contains programs that execute a standard set of commands 8 comprising read, write, protect, and other commands.
- the read and write commands programmed into the mask ROM 3 can be used to read and write data in the data memory 4.
- the protect command can be used to protect specified data in the data memory 4 from further alteration by the write command.
- the mask ROM 3 also contains an initialize command program 9 that releases the protection set by the protect command and restores the data memory 4 to its initial state, erasing any data written by the write command.
- the protect command can be programmed to write-protect specified areas of the data memory 4 by setting corresponding protection bits in the data memory 4.
- the write command may comprise a check routine that prevents the write command from (1) setting or clearing any protection bits; and (2) writing into a write-protected area, i.e. an area the protection bit of which is set.
- the initialize command 9 can erase the entire data memory 4, thereby also clearing the protection bits.
- the write, protect, and initialize commands are programmed so that they can only be executed by first entering a password.
- the password is, for example, stored in the RAM 5, and checked by comparison with a password value stored in the data memory 4. This password protection can be removed from the write command, and possibly from other commands, when the card is issued.
- the password value stored in the data memory 4 is an initial all-zero or all-one value.
- the card manufacturer 6 After manufacturing the blank prototype card 7, the card manufacturer 6 proceeds to protect it by changing the password, thereby converting the blank prototype card 7 to a protected prototype card 10. Specifically, the card manufacturer enters the initial (all-zero or all-one) password, thereby gaining the right to execute the write command, then uses the write command to write a manufacturer's password 11 in the data memory 4.
- the manufacturer's password 11 is known to both the card manufacturer and card issuer 12, but is kept secret from other parties.
- the card issuer 12 When the card issuer 12 receives the protected prototype card 10 from the card manufacturer 6, he uses his issuing program to write data in the data memory 4, thereby converting the card to an issued prototype card 13. Specifically, the issuing program enters the manufacturer's password 11, thereby gaining the right to execute the write command. Next, the issuing program uses the write command to change the manufacturer's password 11 to an issuer's password 14 which is known only to the issuer. Then the issuing program writes issuer data 15 and application data 16 in the data memory 4, and uses the protect command to protect the password 14 and appropriate parts of the issuer data 15 and application data 16 from further alteration.
- the issued prototype card 13 has been issued to an imaginary end user whose name and other end-user data all have initial (all-zero or all-one) values.
- the card issuer 12 uses the issued prototype card 13 for test purposes, as described later. After testing is completed, the card issuer 12 orders a quantity of production cards from the card manufacturer 6.
- a blank production card 17 is the same as a blank prototype card 7 except that in place of the initialize command 9, it has a version read command 18 which reads a version number.
- the version number is preferably a number stored in the mask ROM 3 that distinguishes the production card from a prototype card.
- Prototype cards have either a different version number, or no version number.
- the version number can be embedded in the version read command program, which is lacking in prototype cards.
- the card manufacturer 6 After manufacturing a blank production card 17, the card manufacturer 6 converts it to a protected production card 19 by writing the manufacturer's password 11, then ships it to the card issuer 12.
- the card issuer 12 Upon receiving a protected production card 19, the card issuer 12 promptly uses the issuing program to write the issuer's password 14, issuer data 15, and application data 16 in the data memory 4 and protect appropriate parts of these data from further alteration, thereby converting the card to an issued production card 20.
- the card issuer 12 transfers the card to an end user 21, he uses the issuing program again to convert the card to a personalized production card 22.
- the issuing program now enters the issuer's password 14, then uses the write command to write end-user data 23 in the data memory 4.
- the end-user data 23 comprises, for example, the end user's name, address, and a personal identity number (PIN), this latter being a secret code known only to the card issuer 12 and end user 21.
- PIN personal identity number
- the issuing program may also protect appropriate parts of the end-user data 23 from alteration, remove password protection from the write command and possibly other commands as noted above, and substitute alternative forms of protection based on, for example, the end user's PIN.
- the end user 21 can now use the personalized production card 22 for its intended purpose, e.g. for conducting financial transactions.
- step S1 the card manufacturer protects the prototype card by writing the manufacturer's password in it.
- step S2 the card manufacturer ships the prototype card to the card issuer.
- step S3 the card issuer receives delivery of the prototype card.
- step S4 the card issuer issues the prototype card, using the issuing program which is under development.
- step S5 the prototype card is tested and evaluated by, for example, inserting it in a card-testing device. If step S5 indicates that the issuing program needs to be modified, this is done in step S6, then the card is initialized in step S7, using the initialize command.
- step S8 the card issuer enters the initial (all-zero or all-one) password value, then executes the write command to change the password to the manufacturer's password, thereby restoring the card to its state upon delivery in step S3.
- step S4 the card is reissued, using the modified issuing program, then tested and evaluated again.
- the prototype card can be cycled through steps S4, S5, S6, S7, and S8 as many times as necessary until the issuing program has been completed, and has been thoroughly tested and debugged.
- step S9 the card issuer declares the issuing program completed.
- the issuing program can accordingly be completely developed, tested, and debugged using only a single prototype card. It is not necessary to spoil large quantities of production cards as in the prior art.
- Fig. 4 illustrates the issuing of a production card.
- the card manufacturer protects the production card by writing the manufacturer's password.
- the card manufacturer ships the production card to the card issuer, who receives delivery in step S13.
- the card issuer issues the production card, using the completed issuing program, and personalizes it with end-user data.
- the personalized card is delivered to the end user.
- Fig. 5 illustrates the use of a personalized production card by the end user.
- the end user inserts the card in a card-handling device at, for example, a bank, and the device detects that the card has been inserted.
- a standard program in the device instructs the card to execute the version read command, thereby reading the version number from the card.
- the version number is checked. If the version number is appropriate, in step S24 an application program is started.
- step S25 the application program reads and checks application data stored in the card. If this check passes, in step S26 the application program performs the service it has been programmed to provide, such as carrying out a financial transaction. When this service is completed, in step S27 the application program ends, and in step S28 the card is ejected.
- step S23 The process in Fig. 5 has several built-in safeguards.
- the card is not programmed to execute the version read command (e.g., if the card is a prototype card) the version check in step S23 will obviously fail. Failure of the check in step S23 causes a jump to step S28, ejecting the card.
- the version number recorded in the card is inappropriate, the result in step S23 will again be negative and the card will again be ejected.
- step S25 the application data read in step S25 are inappropriate (for example, if the card was issued by a different issuer)
- the application program will jump to step S28, once again ejecting the card.
- the invented card system accordingly provides the same security features as in the prior art.
- a production card is protected first by the manufacturer's password, then by the issuer's password, and also by the permanent write protection applied to various data when the card issued, which prevents the card from being reissued.
- a prototype card is even more strongly protected, because it lacks the version read command.
- a prototype card When inserted in a card-handling device, a prototype card will fail the version check in step S23 in Fig. 5 and be ejected before any application processing can begin. Accordingly, even if someone obtains a blank prototype card 7 that is not protected by a password, although he can tamper with the contents of the card to his heart's content, he cannot make any use of the card. The same applies to someone who steals a protected prototype card 10 or issued prototype card 13.
- the version number is stored in the mask ROM 3, it is possible to provide the prototype card with a version read command without compromising the security of the system, as long as prototype cards and production cards have different version numbers. If inserted in a card-handling device, a prototype card will still fail the version check in step S23 in Fig. 5, this check being adapted to reject cards having prototype version numbers.
- the initialize command was described as restoring a prototype card to the blank state, so that the issuer had to write the manufacturer's password to return the card to its condition upon delivery.
- An alternative scheme is to have the initialize command write the manufacturer's password.
- the manufacturer can use two different passwords, one for prototype cards and one for production cards.
- the prototype card can be used not only during development of the issuing program, but also during development of application programs and other system software.
Abstract
Description
- This invention relates to an IC card system such as a bank card system, more particularly to an IC card system that is secure, yet can be developed without spoiling a large number of cards.
- Wallet-size cards, similar in appearance to ordinary credit cards but having embedded integrated circuits (ICs), are issued by institutions such as banks as a convenient means of managing financial and other data. Popularly known as "smart cards," these cards will be referred to herein as IC cards. An IC card system comprises not only the IC cards themselves but also various software. The software includes, for example, an issuing program used in issuing the cards to end users, and application programs used to process the cards when they are inserted in card-handling devices such as automatic teller machines.
- A feature of IC card systems is that they can be made extremely secure by protecting the cards with passwords, and by protecting certain data in the cards from alteration even by a person who knows the password. Typically, the cards are manufactured by one entity (the card manufacturer), then issued by another entity (the card issuer) to end users. In one conventional system, the card manufacturer programs the cards with a manufacturer's password known only to the card manufacturer and card issuer. Upon receiving a card from the card manufacturer, the card issuer changes the password to an issuer's password known only to the card issuer, stores certain issuer data and application data in the card, and sets protection bits that permanently prevent some of these data from being altered. When the card issuer issues the card to an end user, he stores further information in the card, such as the user's name, address, and personal identity number. Some of this information may also be permanently protected from alteration.
- An end user cannot tamper with the data in his card because he does not know the issuer's password. If the card is stolen by a third party, that party cannot tamper with the card for the same reason. If the third party steals a card from the card manufacturer, he still cannot tamper with it because he does not know the manufacturer's password. The card manufacturer himself is unable to tamper with a card once the card issuer has changed the password. Furthermore, even if someone who knew the issuer's password were to use it to gain unauthorized access to an already-issued card, he would be unable to reissue the card to himself because of the permanent protection of data in the card. In this way an IC card can be made secure against virtually any kind of attack, whether it be by an end user, a third party, the card manufacturer, or an employee of the card-issuing institution.
- A disadvantage of these security arrangements, however, is that the card issuer is forced to expend a large number of cards in the process of developing and debugging his software. This is particularly true when the software is developed through a trial-and- error process, which is often the case. Consider, for example, a card issuer who is developing an issuing program. He completes a first version of the program and tests it by issuing a first card to an imaginary end user. The card is then evaluated by checking that it contains correct data and works correctly with application software. If any deficiencies are found, the issuing program is modified, and the modified program is tested by issuing a second card. Even if no problems are found, additional cards are issued to test the program under different sets of issuing conditions.
- This process is repeated until the issuing program has been completely developed, tested, and debugged. A new card is required for each test, because the permanent data protection applied when each card is issued prevents the card from being reused for another test. Each test accordingly spoils one card. As the program development process typically involves many tests, many cards must be sacrificed in this way.
- It is accordingly an object of the present invention to enable IC card system software to be developed and tested without spoiling IC cards.
- Another object of the invention is to maintain existing levels of security.
- The invented IC card system uses a set of IC cards comprising a prototype card and one or more production cards. The prototype card is programmed to execute a standard set of commands for reading and writing data in the card, and an initialize command for initializing these data. During development of system software, the software can be tested by repeatedly issuing, initializing, and reissuing the prototype card.
- Production cards are programmed to execute the same standard set of commands, and a version read command. The version read command reads out a version number distinguishing a production card from the prototype card. Production cards are not programmed to execute the initialize command. Production cards are personalized with end user data and distributed to end users.
-
- Fig. 1 is a block diagram of an integrated circuit in an IC card.
- Fig. 2 illustrates prototype and production cards in various stages of programming.
- Fig. 3 is a flowchart illustrating the use of a prototype card to develop a card-issuing program.
- Fig. 4 is a flowchart illustrating the issuing of production cards.
- Fig. 5 is a flowchart illustrating the use of production cards by end users.
- An embodiment of the invention will be described with reference to the attached drawings. These drawings illustrate the invention but do not restrict its scope, which should be determined solely from the appended claims.
- Fig. 1 is a block diagram of an integrated circuit that may be used in the invented IC card system. The circuit comprises a central processing unit (CPU) 1, an
interface 2, a mask-programmable read-only memory (mask ROM) 3, anon-volatile data memory 4, and a volatile random-access memory (RAM) 5. Theinterface 2 enables theCPU 1 to communicate with an external card-handling device such as an automatic teller machine. Thedata memory 4 comprises, for example, so-called flash memory, orelectrical- ly-erasable programmable read-only memory (EE-PROM). TheRAM 5 is used as a work area during program execution. The circuit blocks in Fig. 1 are well known to those skilled in the art, so detailed descriptions will be omitted. - IC cards containing the integrated circuit in Fig. 1 are supplied from a card manufacturer to a card issuer, who then issues them to end users. The card manufacturer may manufacture the integrated circuit himself, or he may obtain it from an IC manufacturer. In either case, the card manufacturer programs the
mask ROM 3, e.g. by supplying the IC manufacturer with mask data. Once the IC is manufactured, it is physically impossible to alterthe contents of themask ROM 3. The contents of thedata memory 4, in contrast, can be altered. Thedata memory 4 is programmed by both the card manufacturer and card issuer. - Fig. 2 illustrates two types of IC cards in various stages of programming, indicating the contents of their mask-
programmable ROM 3 anddata memory 4. One of these types, illustrated at the top of Fig. 2, is a prototype card used by the card issuer during program development. The other type, illustrated at the bottom of Fig. 2, is a production card, which is distributed to end users. - When the
card manufacturer 6 manufactures a prototype card, it is originally a blank prototype card 7. "Blank" means that thedata memory 4 is in an initial state containing, for example, all-one data, or all-zero data. Themask ROM 3 of a blank prototype card 7 contains programs that execute a standard set ofcommands 8 comprising read, write, protect, and other commands. The read and write commands programmed into themask ROM 3 can be used to read and write data in thedata memory 4. The protect command can be used to protect specified data in thedata memory 4 from further alteration by the write command. Themask ROM 3 also contains aninitialize command program 9 that releases the protection set by the protect command and restores thedata memory 4 to its initial state, erasing any data written by the write command. - Details of the programming of the above commands will be familiar to those skilled in the art. For example, the protect command can be programmed to write-protect specified areas of the
data memory 4 by setting corresponding protection bits in thedata memory 4. The write command may comprise a check routine that prevents the write command from (1) setting or clearing any protection bits; and (2) writing into a write-protected area, i.e. an area the protection bit of which is set. Theinitialize command 9 can erase theentire data memory 4, thereby also clearing the protection bits. - The write, protect, and initialize commands (and possibly other commands) are programmed so that they can only be executed by first entering a password. When entered, the password is, for example, stored in the
RAM 5, and checked by comparison with a password value stored in thedata memory 4. This password protection can be removed from the write command, and possibly from other commands, when the card is issued. In the blank prototype card 7, the password value stored in thedata memory 4 is an initial all-zero or all-one value. - After manufacturing the blank prototype card 7, the
card manufacturer 6 proceeds to protect it by changing the password, thereby converting the blank prototype card 7 to a protected prototype card 10. Specifically, the card manufacturer enters the initial (all-zero or all-one) password, thereby gaining the right to execute the write command, then uses the write command to write a manufacturer's password 11 in thedata memory 4. The manufacturer's password 11 is known to both the card manufacturer andcard issuer 12, but is kept secret from other parties. - When the
card issuer 12 receives the protected prototype card 10 from thecard manufacturer 6, he uses his issuing program to write data in thedata memory 4, thereby converting the card to an issued prototype card 13. Specifically, the issuing program enters the manufacturer's password 11, thereby gaining the right to execute the write command. Next, the issuing program uses the write command to change the manufacturer's password 11 to an issuer'spassword 14 which is known only to the issuer. Then the issuing program writesissuer data 15 andapplication data 16 in thedata memory 4, and uses the protect command to protect thepassword 14 and appropriate parts of theissuer data 15 andapplication data 16 from further alteration. - At this point the issued prototype card 13 has been issued to an imaginary end user whose name and other end-user data all have initial (all-zero or all-one) values. The
card issuer 12 uses the issued prototype card 13 for test purposes, as described later. After testing is completed, thecard issuer 12 orders a quantity of production cards from thecard manufacturer 6. - A
blank production card 17 is the same as a blank prototype card 7 except that in place of theinitialize command 9, it has a version readcommand 18 which reads a version number. The version number is preferably a number stored in themask ROM 3 that distinguishes the production card from a prototype card. Prototype cards have either a different version number, or no version number. For example, the version number can be embedded in the version read command program, which is lacking in prototype cards. - After manufacturing a
blank production card 17, thecard manufacturer 6 converts it to a protectedproduction card 19 by writing the manufacturer's password 11, then ships it to thecard issuer 12. Upon receiving a protectedproduction card 19, thecard issuer 12 promptly uses the issuing program to write the issuer'spassword 14,issuer data 15, andapplication data 16 in thedata memory 4 and protect appropriate parts of these data from further alteration, thereby converting the card to an issuedproduction card 20. - When the
card issuer 12 transfers the card to anend user 21, he uses the issuing program again to convert the card to apersonalized production card 22. Specifically, the issuing program now enters the issuer'spassword 14, then uses the write command to write end-user data 23 in thedata memory 4. The end-user data 23 comprises, for example, the end user's name, address, and a personal identity number (PIN), this latter being a secret code known only to thecard issuer 12 andend user 21. The issuing program may also protect appropriate parts of the end-user data 23 from alteration, remove password protection from the write command and possibly other commands as noted above, and substitute alternative forms of protection based on, for example, the end user's PIN. Theend user 21 can now use thepersonalized production card 22 for its intended purpose, e.g. for conducting financial transactions. - The use of a prototype card in developing an issuing program is illustrated in Fig. 3. In step S1, the card manufacturer protects the prototype card by writing the manufacturer's password in it. In step S2, the card manufacturer ships the prototype card to the card issuer. In step S3, the card issuer receives delivery of the prototype card. In step S4, the card issuer issues the prototype card, using the issuing program which is under development. In step S5 the prototype card is tested and evaluated by, for example, inserting it in a card-testing device. If step S5 indicates that the issuing program needs to be modified, this is done in step S6, then the card is initialized in step S7, using the initialize command. In step S8 the card issuer enters the initial (all-zero or all-one) password value, then executes the write command to change the password to the manufacturer's password, thereby restoring the card to its state upon delivery in step S3.
- The procedure now returns to step S4: the card is reissued, using the modified issuing program, then tested and evaluated again. The prototype card can be cycled through steps S4, S5, S6, S7, and S8 as many times as necessary until the issuing program has been completed, and has been thoroughly tested and debugged. When all tests are finished and a satisfactory result is obtained in step S5, then in step S9 the card issuer declares the issuing program completed.
- The issuing program can accordingly be completely developed, tested, and debugged using only a single prototype card. It is not necessary to spoil large quantities of production cards as in the prior art.
- Fig. 4 illustrates the issuing of a production card. In step S11, the card manufacturer protects the production card by writing the manufacturer's password. In step S12, the card manufacturer ships the production card to the card issuer, who receives delivery in step S13. In step S14, the card issuer issues the production card, using the completed issuing program, and personalizes it with end-user data. In step S15 the personalized card is delivered to the end user.
- Fig. 5 illustrates the use of a personalized production card by the end user. In step S21, the end user inserts the card in a card-handling device at, for example, a bank, and the device detects that the card has been inserted. In step S22, a standard program in the device instructs the card to execute the version read command, thereby reading the version number from the card. In step S23, the version number is checked. If the version number is appropriate, in step S24 an application program is started. In step S25 the application program reads and checks application data stored in the card. If this check passes, in step S26 the application program performs the service it has been programmed to provide, such as carrying out a financial transaction. When this service is completed, in step S27 the application program ends, and in step S28 the card is ejected.
- The process in Fig. 5 has several built-in safeguards. First, if the card is not programmed to execute the version read command (e.g., if the card is a prototype card) the version check in step S23 will obviously fail. Failure of the check in step S23 causes a jump to step S28, ejecting the card. Second, if the version number recorded in the card is inappropriate, the result in step S23 will again be negative and the card will again be ejected. Third, if the application data read in step S25 are inappropriate (for example, if the card was issued by a different issuer), the application program will jump to step S28, once again ejecting the card.
- The invented card system accordingly provides the same security features as in the prior art. A production card is protected first by the manufacturer's password, then by the issuer's password, and also by the permanent write protection applied to various data when the card issued, which prevents the card from being reissued.
- A prototype card is even more strongly protected, because it lacks the version read command. When inserted in a card-handling device, a prototype card will fail the version check in step S23 in Fig. 5 and be ejected before any application processing can begin. Accordingly, even if someone obtains a blank prototype card 7 that is not protected by a password, although he can tamper with the contents of the card to his heart's content, he cannot make any use of the card. The same applies to someone who steals a protected prototype card 10 or issued prototype card 13.
- The IC card system described above is only one of many possible embodiments of the invention. It can be modified in numerous ways. For example:
- The version number was described as stored in the
mask ROM 3, where it cannot be altered. Since prototype cards lack the version read command, however, it is possible to store the version number in thedata memory 4. This provides additional flexibility, since it permits the card issuer to write different version numbers without having to order changes in mask-ROM data. - If the version number is stored in the
mask ROM 3, it is possible to provide the prototype card with a version read command without compromising the security of the system, as long as prototype cards and production cards have different version numbers. If inserted in a card-handling device, a prototype card will still fail the version check in step S23 in Fig. 5, this check being adapted to reject cards having prototype version numbers. - The initialize command was described as restoring a prototype card to the blank state, so that the issuer had to write the manufacturer's password to return the card to its condition upon delivery. An alternative scheme is to have the initialize command write the manufacturer's password. For further security, the manufacturer can use two different passwords, one for prototype cards and one for production cards.
- The prototype card can be used not only during development of the issuing program, but also during development of application programs and other system software.
- Those skilled in the art will recognize that still further modifications can be made without departing from the scope of the invention as claimed below.
Claims (15)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP4277256A JP2935613B2 (en) | 1992-10-15 | 1992-10-15 | IC card and IC card system |
JP277256/92 | 1992-10-15 |
Publications (3)
Publication Number | Publication Date |
---|---|
EP0593244A2 true EP0593244A2 (en) | 1994-04-20 |
EP0593244A3 EP0593244A3 (en) | 1995-05-24 |
EP0593244B1 EP0593244B1 (en) | 1998-01-21 |
Family
ID=17580996
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP93308087A Expired - Lifetime EP0593244B1 (en) | 1992-10-15 | 1993-10-11 | Secure IC card system with reusable prototype card |
Country Status (4)
Country | Link |
---|---|
US (1) | US5442165A (en) |
EP (1) | EP0593244B1 (en) |
JP (1) | JP2935613B2 (en) |
DE (1) | DE69316516T2 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1996028793A2 (en) * | 1995-03-10 | 1996-09-19 | Siemens Aktiengesellschaft | Licence-card-controlled chip card system |
US6112985A (en) * | 1996-03-07 | 2000-09-05 | Siemens Aktiengesellschaft | License-card-controlled chip card system |
FR2809847A1 (en) * | 2000-06-06 | 2001-12-07 | Gemplus Card Int | Electrical personalizing of open platform chip card by personalizing application program code source by compiling prior to loading to chip card using personalized code source |
EP0778553A3 (en) * | 1995-12-08 | 2002-05-15 | Kabushiki Kaisha Toshiba | Portable storage medium issuing system and issuing method |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0896106A (en) * | 1994-09-29 | 1996-04-12 | Mitsubishi Electric Corp | Ic card and ic card system |
US5889941A (en) * | 1996-04-15 | 1999-03-30 | Ubiq Inc. | System and apparatus for smart card personalization |
US6202155B1 (en) | 1996-11-22 | 2001-03-13 | Ubiq Incorporated | Virtual card personalization system |
JPH10214232A (en) * | 1997-01-30 | 1998-08-11 | Rohm Co Ltd | Ic card, and ic card operating method |
US6402028B1 (en) | 1999-04-06 | 2002-06-11 | Visa International Service Association | Integrated production of smart cards |
US6804730B1 (en) * | 1999-11-17 | 2004-10-12 | Tokyo Electron Device Limited | Access control device, access control method, recording medium, and computer data signal for controlling allowance of access to storage area using certification data |
EP1187065A3 (en) * | 2000-09-05 | 2002-07-31 | ACG Aktiengesellschaft für Chipkarten und Informationssysteme | Method for batch manufacturing of chips, in particular for SIM cards |
JP2005134953A (en) * | 2003-10-28 | 2005-05-26 | Dainippon Printing Co Ltd | Unset ic card, ic card issue system, and method for issuing ic card application |
FR2865085B1 (en) * | 2004-01-08 | 2006-07-21 | Ercom Engineering Reseaux Comm | KEY MANAGEMENT SYSTEM FOR CRYPTOPHONIC USE, IN PARTICULAR BY IMPLEMENTING PUBLIC KEY MANAGEMENT (PKI) INFRASTRUCTURE |
US20050197859A1 (en) * | 2004-01-16 | 2005-09-08 | Wilson James C. | Portable electronic data storage and retreival system for group data |
US7922081B2 (en) * | 2004-04-01 | 2011-04-12 | Hitachi, Ltd. | Identification information managing method and system |
JP4706220B2 (en) | 2004-09-29 | 2011-06-22 | ソニー株式会社 | Information processing apparatus and method, recording medium, and program |
US8401964B2 (en) * | 2009-04-28 | 2013-03-19 | Mastercard International Incorporated | Apparatus, method, and computer program product for encoding enhanced issuer information in a card |
US8533484B2 (en) * | 2010-03-29 | 2013-09-10 | Verifone, Inc. | Password-protected physical transfer of password-protected devices |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4855578A (en) * | 1986-08-28 | 1989-08-08 | Kabushiki Kaisha Toshiba | Portable storage medium processing system |
US5039850A (en) * | 1990-06-15 | 1991-08-13 | Mitsubishi Denki Kabushiki Kaisha | IC card |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3041393C2 (en) * | 1980-11-03 | 1984-05-17 | Stockburger, Hermann, 7742 St Georgen | Method for creating a predetermined number of authorization cards having a storage medium |
JP2564480B2 (en) * | 1985-07-16 | 1996-12-18 | カシオ計算機株式会社 | IC card system |
JPH0259937A (en) * | 1988-08-26 | 1990-02-28 | Hitachi Maxell Ltd | Ic card |
JP2682700B2 (en) * | 1989-05-09 | 1997-11-26 | 三菱電機株式会社 | IC card |
-
1992
- 1992-10-15 JP JP4277256A patent/JP2935613B2/en not_active Expired - Fee Related
-
1993
- 1993-10-11 EP EP93308087A patent/EP0593244B1/en not_active Expired - Lifetime
- 1993-10-11 DE DE69316516T patent/DE69316516T2/en not_active Expired - Fee Related
- 1993-10-14 US US08/136,038 patent/US5442165A/en not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4855578A (en) * | 1986-08-28 | 1989-08-08 | Kabushiki Kaisha Toshiba | Portable storage medium processing system |
US5039850A (en) * | 1990-06-15 | 1991-08-13 | Mitsubishi Denki Kabushiki Kaisha | IC card |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1996028793A2 (en) * | 1995-03-10 | 1996-09-19 | Siemens Aktiengesellschaft | Licence-card-controlled chip card system |
WO1996028793A3 (en) * | 1995-03-10 | 1997-01-03 | Siemens Ag | Licence-card-controlled chip card system |
EP0778553A3 (en) * | 1995-12-08 | 2002-05-15 | Kabushiki Kaisha Toshiba | Portable storage medium issuing system and issuing method |
US6112985A (en) * | 1996-03-07 | 2000-09-05 | Siemens Aktiengesellschaft | License-card-controlled chip card system |
FR2809847A1 (en) * | 2000-06-06 | 2001-12-07 | Gemplus Card Int | Electrical personalizing of open platform chip card by personalizing application program code source by compiling prior to loading to chip card using personalized code source |
WO2001095271A1 (en) * | 2000-06-06 | 2001-12-13 | Gemplus | Method for electrical customization of smart card |
Also Published As
Publication number | Publication date |
---|---|
DE69316516T2 (en) | 1998-08-27 |
JPH06131515A (en) | 1994-05-13 |
EP0593244B1 (en) | 1998-01-21 |
EP0593244A3 (en) | 1995-05-24 |
JP2935613B2 (en) | 1999-08-16 |
US5442165A (en) | 1995-08-15 |
DE69316516D1 (en) | 1998-02-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5442165A (en) | Secure IC card system with reusable prototype IC card | |
EP0275510B1 (en) | Smart card having external programming capability and method of making same | |
RU2214008C2 (en) | Protected memory having plurality of protection levels | |
US6094724A (en) | Secure memory having anti-wire tapping | |
US4734568A (en) | IC card which can set security level for every memory area | |
US5754762A (en) | Secure multiple application IC card using interrupt instruction issued by operating system or application program to control operation flag that determines the operational mode of bi-modal CPU | |
US6659354B2 (en) | Secure multi-application IC card system having selective loading and deleting capability | |
JP2002512715A (en) | Secure multi-application card system and process | |
JPH0682405B2 (en) | Test program start method | |
US5039850A (en) | IC card | |
JPH021090A (en) | Ic card and method for writing its operation program | |
JPS62190584A (en) | Portable electronic device | |
US5828053A (en) | Portable storage medium and portable storage medium issuing system | |
AU692573B2 (en) | Testing of memory content | |
EP1053535A1 (en) | Configuration of ic card | |
JP3251579B2 (en) | Portable electronic devices | |
JPH06309531A (en) | Checking method for instruction format given to ic card | |
US7681029B1 (en) | Method and device for controlling a portable object life cycle, in particular a smart card | |
JPH01233690A (en) | Ic card | |
JPS60153581A (en) | Ic card having function inhibiting illegal use | |
JPH11282992A (en) | Ic card | |
JPH01177184A (en) | Portable electronic device | |
JPH01177183A (en) | Portable electronic device | |
JPS62221050A (en) | Data management system for ic card | |
JPH01177185A (en) | Portable electronic device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): DE FR GB |
|
PUAL | Search report despatched |
Free format text: ORIGINAL CODE: 0009013 |
|
AK | Designated contracting states |
Kind code of ref document: A3 Designated state(s): DE FR GB |
|
17P | Request for examination filed |
Effective date: 19950829 |
|
17Q | First examination report despatched |
Effective date: 19960411 |
|
GRAG | Despatch of communication of intention to grant |
Free format text: ORIGINAL CODE: EPIDOS AGRA |
|
GRAH | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOS IGRA |
|
GRAH | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOS IGRA |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): DE FR GB |
|
ET | Fr: translation filed | ||
REF | Corresponds to: |
Ref document number: 69316516 Country of ref document: DE Date of ref document: 19980226 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
26N | No opposition filed | ||
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20011010 Year of fee payment: 9 Ref country code: FR Payment date: 20011010 Year of fee payment: 9 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20011029 Year of fee payment: 9 |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: IF02 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20021011 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: DE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20030501 |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20021011 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20030630 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: ST |