Abstract:
A method for low-level security based on the UID. In particular it enhances an RFID system by adding the ability to dynamically modify the UID of the smartcard or to randomly generate a new UID for the smartcard.

Description:
The present application is a continuation-in-part of pending U.S. patent application Ser. No. 12/967,059 filed on Dec. 14, 2010, the entire disclosure of which is incorporated herein by reference. 
    
    
     BACKGROUND 
     Smartcard, chip card or integrated circuit card is typically any pocket-sized card with embedded integrated circuits. Contactless smartcards typically are RFID (Radio Frequency Identification) type cards which suffer from collision problems. Collisions can occur when more than one smartcard is in the vicinity of the reader device. To help address the collision problem, smartcards typically support card ID (Identification) codes. 
     Two types of ID codes are the fixed Unique ID (UID) and the Random ID. A fixed UID code typically serves two functions. The UID is used in the anti-collision process to distinguish between multiple cards presented in parallel in the vicinity of the reader device and address the cards individually. A UID is also used by the reader device to ascertain the identity of a hardcoded or virtual card device to determine which keys to use when addressing the device. The Random-ID code is typically newly generated at each Power-UP of the card and is stored in RAM. Hence, when a Random-ID code scheme is used by the card, the reader device typically receives a new Random-ID from the card each time the card is brought into the RF-field of the reader device. 
     Some applications that use fixed UIDs, typically in the customer card area, have been rejected by users or card issuers because a large number of users objected to the full trackability of the smartcards having UIDs from location to location. Particularly for smartcards with RFID or other contactless interfaces, protection against unwanted tracking of interactions with reader devices or tracking of location changes is typically desirable from a user point of view. The use of Random-IDs is recommended from both a security and privacy point of view for secure cards to prevent individual cards from being tracked from location to location where the Random-ID code is exposed during the anti-collision process. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows an embodiment in accordance with the invention. 
         FIG. 2  shows an embodiment in accordance with the invention. 
         FIG. 3   a  shows an embodiment in accordance with the invention. 
         FIG. 3   b  shows an embodiment in accordance with the invention. 
         FIG. 4   a  shows an embodiment in accordance with the invention. 
         FIG. 4   b  shows an embodiment in accordance with the invention. 
     
    
    
     DETAILED DESCRIPTION 
     In accordance with the invention, a smartcard is implemented that combines the capabilities of a fixed UID code with that of a changing Random-ID code by changing the Random-ID code only at specific times under the control of the card user. In some embodiments in accordance with the invention, for arbitrary time periods the smartcard can be used like a smartcard having a fixed UID code, allowing tracking from card reader location to card reader location and allowing collection of the history information about all interactions of the smartcard in the time between two Random-ID code generations. In accordance with the invention, smartcards requiring only low-security based on UID codes, the UID code may be changed dynamically based on a UID sent from the reader device to the RFID smartcard or the UID is changed dynamically based on a random number generator in the RFID smartcard where the smartcard sends the newly generated UID to the card reader. 
     Embodiments in accordance with the invention provide an integrated circuit card capable of generating Random-ID codes in response to requests by the card user via an external interface or allow dynamic changes of the UID code. 
     In an embodiment in accordance with the invention, the most recently generated Random-ID code is typically stored in an on-chip non-volatile non-secure memory so that it may be used as a quasi-static ID code or “PseudofixedRandomUID” until the next Random-ID code generation is triggered by the card user. Until a new Random-ID code is generated, the stored Random-ID is used during the anti-collision process each time the card is activated by a reader device, even if the card has experienced a reset event such as a Power-Down or reader RF-field off event. Therefore, until a new Random-ID is generated in response to a user request, the card operates as a card configured to use a fixed UID. 
       FIG. 1  shows an embodiment in accordance with the invention. Smartcard  10  incorporates user-controlled Random-ID code generation. Smartcard  10  has user interface  190  which allows the card user to generate and store a new Random-ID code, “PseudoFixedRandomUID” in nonvolatile non-secure memory  112   a . User interface  190  may be implemented as, for example, a push button or other suitable device electrically coupled to I/O handler  185 . Each time the card user pushes the button of user interface  190 , smartcard  10  will internally generate a new Random-ID code using random number generator  170  which is electrically coupled to smartcard microcontroller kernel  180 . Smartcard microcontroller kernel  180  is electrically coupled to both nonvolatile secure memory  112   b  and nonvolatile non-secure memory  112   a . Secure memory  112   b  is characterized by having restricted access rights that limit the operation modes during which it may be read or written to by microcontroller kernel  180  (more generally the CPU) and cannot be freely accessed by peripheral blocks such as, for example, a universal asynchronous receiver/transmitter, a direct memory interface or an I/O port. Hence, kernel  180  is able to access both nonvolatile secure memory  112   b  and nonvolatile non-secure memory  112   a  separately in operation modes with different security levels. For certain secure operation modes, such as the boot-phase or the smartcard authentication procedure, kernel  180  has access to portions of non-volatile secure memory  112   b  that are not accessible in other operation modes. This hardware-implemented security feature prevents application software running on kernel  180  from accessing keycodes, error flags and security related data needed in the secure operation mode. Smartcard  10  interacts with card reader system  100  which is electrically coupled to card reader user interface  110  and card reader network interface  120 . 
     User interface  190  may be implemented in an embodiment in accordance with the invention as a dedicated firmware function that can be called and executed by a user software package installed on smartcard  10 . This embodiment is typically suitable when smartcard  10  is embedded in a larger communication or identification environment such as, for example, a mobile phone, a portable computer or a tablet computer, and allows the generation and storage of a new Random-ID code to be initiated by a special menu option in the User Menu of the device. 
     In an embodiment in accordance with the invention, power to smartcard  10  may be buffered by energy storage component  160  which is electrically coupled to power supply control unit  150  that is either integrated into smartcard  10  as shown in  FIG. 1  or is part of the environment, for example, a mobile phone or other suitable portable electronic device, in which smartcard  10  is operated. Energy storage component  160  insures that sufficient power is available to initiate and execute the generation of a new Random-ID code for smartcard  10 . When the user initiates the generation of a new Random-ID code, energy storage component  160  supplies power to smartcard microcontroller kernel  180  and non-volatile non-secure memory  112   a  which stores the Random-ID code, “PseudoFixedRandomUID” and application related public data such as, for example, address lists and Internet links, and non-volatile secure memory  112   b  which stores encryption key data, status flags and error counters. Note that the typical prior-art Random-ID code is a session related ID for smartcard  10  which is regenerated anytime that smartcard  10  is newly introduced to card reader system  100  and deleted at the end of the interaction with card reader system  100 . Therefore, the typical prior-art Random-ID code is typically stored in RAM (volatile memory). However, in accordance with the invention, the Random-ID code, “PseudoFixedRandomUID”, is fixed over multiple communication sessions with different card reader systems  100  (e.g. at different locations) until the user initiates the generation of a new Random-ID code, “PseudoFixedRandomUID”. Because the Random-ID code in accordance with the invention is used like a fixed UID code for user determined periods of time and is transmitted openly by smartcard  10  to card reader system  100  at the start of each communication session, the Random-ID code is stored in nonvolatile non-secure memory  112   a.    
     Nonvolatile secure memory  112   b  stores session-keys or login codes that are received by smartcard  10  from the Application Environment when smartcard  10  is newly introduced to card reader system  100 . Typically the Application Environment includes a SmartCard Reader Terminal which is part of a server-network that centrally controls all transactions of SmartCards using the particular application. Non-volatile secure memory  112   b  also stores private data generated within the Application Environment. This private data typically comprises articles selected for purchase within a supermarket type of environment, services or pages used with an Internet application and points of sale that have been visited by the user in a shopping mall type environment. In accordance with the invention, such private data should only be accessible by the Application Environment that generated the data and only accessible while the “PseudoFixedRandomUID” under which the private data was created is still valid. The private data is encrypted in a two step approach based on an encryption key stored in nonvolatile secure memory  112   b  that is diversified using the current “PseudoFixedRandomUID” stored in nonvolatile non-secure memory  112   a  so that the generation of a new “PseudoFixedRandomUID” by the user invalidates the data stored in non-volatile secure memory  112   b.    
     Energy storage component  160  may include capacitive energy storage that is charged via the RF-field of card reader system  100  or via electrical contact of smartcard  10  with card reader system  100 . Capacitive energy storage allows a limited number of user actions before power is exhausted. Capacitive energy storage component  160  needs to provide at least enough energy storage to allow the proper completion or proper termination of an executing Random-ID code generation process in the event card smartcard  10  is abruptly removed out of the RF-field of card reader system  100  or out of electrical contact with card reader system  100 . 
     Typically, the power supply for operating smartcard  10  is obtained via the RF-field from card reader system  100  interacting with card interface  130  or from electrical contact by card reader system  100  with card interface  130 . Card interface  130  may include an RF receiver antenna and electrical contact pads for electrically coupling to card reader system  100  in an embodiment in accordance with the invention. Card interface management unit  140  is electrically coupled to card interface  130  and to power supply control unit  150 , I/O handler  185 , random number generator  170 , smartcard microcontroller kernel  180 , and memory  112   a  and  112   b.    
     In an embodiment in accordance with the invention, a back-up battery may be integrated into smartcard  10  which is only used by smartcard core  11  when no external power is available, for example, from card reader system  100 . If smartcard  10  is embedded in a larger communication or identification environment, a back-up battery function may be integrated into the communication or identification environment to supply the back-up power. The availability of additional power allows the use of buffered RAM memory in place of non-volatile EEPROM or flash memory for memory  112   a  and  112   b.    
     In an embodiment in accordance with the invention, smartcard  10  includes an embedded multi-character display as part of user interface  190 . The multi-character display can function to provide information relating to the operation of smartcard  10  such as the time of the latest Random-ID code update, the charge status, error codes, or a status/data display for applications currently being executed on smartcard  10 . 
     In an embodiment in accordance with the invention, smartcard  10  includes an encryption capability for secure memory  112   b  that encrypts or decrypts the contents of that portion of memory  112   b  that contain the card status information and the UID-related card. The encryption of the UID-related card data typically depends on the current Random-ID code, “PseudoFixedRandomUID”, stored in non-volatile non-secure memory  112   a . This provides a key diversification for the secured data. Hence, for each new Random-ID code that is generated by the user, the existing contents of the UID related part of secured memory  112   b  would be invalidated because of the change in the key used for memory access. Therefore, each new Random-ID code generation by the user represents a memory clear of the UID-related portion of nonvolatile secure memory  112   b.    
     In accordance with the invention, the typical smartcard standards need to be modified to accommodate reserved code space for “pseudo UIDs”. Typical smartcard standards have reserved code spaces for genuine UIDs and prior-art Random-IDs. In an embodiment in accordance with the invention, the code space (existing smartcard standards define certain coding spaces for different kinds of IDs) for the targeted “pseudo UIDs” is typically defined as separate from the code spaces reserved for genuine UIDs. Genuine UIDs are the unique ID codes for smartcards  10  that are created by the card manufacturer at the time of smartcard manufacture and the Random-ID codes stored in RAM and re-generated at each smartcard reset when smartcard  10  is newly introduced into the proximity of card reader system  100 . The “PseudoFixedRandomUID” codes in accordance with the invention are stored in non-volatile non-secure memory  112   a  and regenerated only at the discretion of the user. This allows implementations of card reader system  100  that when receiving the UID-code from smartcard  10  can distinguish these types of ID codes and adapt their ID handling processes accordingly. The system within which smartcard  10  is used separates the full coding space for a given ID width into separate value spaces where each space is reserved for a specific ID type (Random-ID, UID, pseudo ID). This means that certain bits in the ID code of smartcard  10  indicate which type of ID-code it is. 
       FIG. 2  shows the relevant life cycle of an embodiment in accordance with the invention. In step  210  of the lifecycle, an initial Random-ID code, “PseudoFixedRandomUID(0)” is generated during production or testing of smartcard  10 . In step  220 , also during production or testing of smartcard  10 , “PseudoFixedRandomUID(0)” is stored in nonvolatile non-secure memory  112   a . Steps following step  220  are performed once smartcard  10  is in possession of the card user. In step  230 , an RF reset is performed. RF reset means that when smartcard  10  enters the RF-field of card reader system  100  or is electrically connected to card reader system  100 , a card reset procedure is initiated by smartcard microcontroller kernel  180 . In step  240  the card user is given the opportunity to generate and store a new Random-ID code, “PseudoFixedRandomUID”. Based on user input through user interface  190 , either a Random-ID code is generated in step  245  using random number generator  170  or virtual card activation of smartcard  10  occurs in step  270  with the current “PseudoFixedRandomUID(N)” stored in nonvolatile non-secure memory  112   a . Virtual activation occurs when smartcard  10  is selected and activated by card reader system  100  which receives the current “PseudoFixedRandomUID(N)” as the fixed card UID. After the step  270 , a check is performed in step  290  to determine if smartcard  10  has reached the end of its lifecycle. If the end of the lifecycle (EOL) has been reached for smartcard  10 , smartcard  10  is inactivated and becomes inoperable in step  295 . If the end of the lifecyle of smartcard  10  has not been reached, an RF reset is performed in step  230  and smartcard  10  awaits user input via user interface  190  regarding generation of a new Random-ID code in step  240 . 
     If the user has generated a new Random-ID code, the new Random-ID code is stored in nonvolatile non-secure memory  112   a  as “PseudoFixedRandomUID(N)” in step  250 . Subsequent to step  250 , an RF reset is performed in step  230  and smartcard  10  awaits user input via user interface  190  regarding generation of a new Random-ID code in step  240 . 
       FIG. 3   a  shows an embodiment in accordance with the invention. Low cost smartcard  30  may incorporate random number generator  330  to generate a new Random-ID code referred to as the “PseudoRandomUID” each time smartcard  30  interacts with card reader system  300  to enhance security and avoid tracking. Card reader system  300  is electrically coupled to card reader user interface  310  and to card reader network interface  320 . Each interaction by smartcard  30  with card reader system  300  results in a new “PseudoRandomUID” being created for smartcard  30 . Random number generator  330  is electrically coupled to smartcard state machine  380  which is electrically coupled to non-secure memory  312 . State machine  380  functions to both store “PseudoRandomUID” in non-secure memory  312  and retrieve “PseudoRandomUID” from non-secure memory  312  as needed to interact with card reader system  300 . 
     In an embodiment in accordance with the invention, power to smartcard  30  may be buffered by energy storage component  360  which is electrically coupled to power supply control unit  350  which is part of smartcard  30 . Energy storage component  360  insures there is sufficient power available for generation of a new Random-ID code for smartcard  30 . Energy storage component  360  may include capacitive energy storage that is charged via the RF-field of card reader system  300 . The capacitive energy storage component  360  needs to be sufficient to provide at least enough energy to allow the proper completion of an executing Random-ID code generation process in the event that smartcard  30  is abruptly removed out of the RF-field of card reader system  300 . 
     Typically, the power supply for operating smartcard  30  is obtained via the RF-field from card reader system  300  interacting with card interface  335 . Card interface  335  may include an RF receiver antenna for electromagnetically coupling to card reader system  300 . Card interface management unit  340  is electrically coupled to card interface  335  and to power supply control unit  350 , I/O handler  384 , random number generator  330 , state machine  380  and non-secure memory  312 . 
     Each time smartcard  30  interacts with card reader system  300  via card reader user interface  310 , energy storage component  360  supplies power to random number generator  330 , state machine  380  and non-secure memory  312  which stores the newly generated Random-ID code, “PseudoRandomUID” for the next interaction with card reader system  300  by smartcard  30 . 
       FIG. 3   b  shows an embodiment in accordance with the invention. Card reader system  300  interacts with smartcard  30  in step  385  where smartcard  30  provides the current “PseudoRandomUID” which is the Random-ID currently associated with smartcard  30  to card reader system  300 . The current “PseudoRandomUID” is also stored locally in card reader system  300  or remotely in a network database accessible to card reader system  300  via card reader network interface  320 . The new “PseudoRandomUID” is generated by random number generator  330  and provided to card reader system  300  in step  387 . Once card reader system  300  verifies that the current “PseudoRandomUID” is valid, card reader system  300  stores the new “PseudoRandomUID” either locally or remotely in the network database and provides a positive response in step  389  which results in smartcard  30  storing the new “PseudoRandomUID” in non-secure memory  312  (see  FIG. 3   a ) for the next interaction with card reader system  300 . Note that the subsequent interaction shown in step  391  may be with a physically different card reader system  300  or the same physical card reader system  300  in accordance with the invention. A benefit of having smartcard  30  generate a new “PseudoRandomUID” with every interaction is that security is enhanced as the “PseudoRandomUID” is used only for a single interaction and it is typically difficult to eavesdrop on the communication from smartcard  30  to card reader system  300  for contactless systems based on inductive fields. 
       FIG. 4   a  shows an embodiment in accordance with the invention. Low cost smartcard  40  does not incorporate a random number generator to generate a new Random-ID code referred to as the “PseudoRandomUID” each time smartcard  40  interacts with card reader system  400  which provides a cost savings for smartcard  40  compared to smartcard  30 . Card reader system  400  is electrically coupled to card reader user interface  410  and to card reader network interface  420 . Each interaction by smartcard  40  with card reader system  400  results in a new “PseudoRandomUID” being provided to smartcard  40  by card reader system  400  to provide security and prevent tracking Smartcard state machine  480  is electrically coupled to non-secure memory  412 . State machine  480  functions to both store “PseudoRandomUID” in non-secure memory  412  and retrieve “PseudoRandomUID” from non-secure memory  412  as needed to interact with card reader system  400 . 
     In an embodiment in accordance with the invention, power to smartcard  40  may be buffered by energy storage component  460  which is electrically coupled to power supply control unit  450  which is part of smartcard  40 . Energy storage component  460  may include capacitive energy storage that is charged via the RF-field of card reader system  400 . The capacitive energy storage component  460  needs to be sufficient to provide at least enough energy to allow the proper completion of executing the Random-ID code transmission process. 
     Typically, the power supply for operating smartcard  40  is obtained via the RF-field from card reader system  400  interacting with card interface  435 . Card interface  435  may include an RF receiver antenna for electromagnetically coupling to card reader system  400 . Card interface management unit  440  is electrically coupled to card interface  435  and to power supply control unit  450 , I/O handler  484 , random number generator  430 , state machine  480  and non-secure memory  412 . 
     Each time smartcard  40  interacts with card reader system  400  via card reader user interface  410 , energy storage component  460  supplies power to state machine  480  and non-secure memory  412  which stores the newly provided Random-ID code, “PseudoRandomUID” for the next interaction with card reader system  400  by smartcard  40 . 
       FIG. 4   b  shows an embodiment in accordance with the invention. Card reader system  400  interacts with smartcard  40  in step  485  where smartcard  40  provides the current “PseudoRandomUID” which is the Random-ID currently associated with smartcard  40  and stored in non-secure memory  412  to card reader system  400 . The current “PseudoRandomUID” associated with smartcard  40  is also stored locally in card reader system  400  or remotely in a network database accessible to card reader system  400  via card reader network interface  420 . A new “PseudoRandomUID” is provided by card reader system  400  in step  489  to smartcard  40  once card reader system  400  verifies that the current “PseudoRandomUID” is valid. This results in smartcard  40  storing the new “PseudoRandomUID” in non-secure memory  412  (see  FIG. 4   a ) for the next interaction with card reader system  400 . Note that the subsequent interaction shown in step  491  where card reader system  400  gets the new “PseudoRandomUID” from smartcard  40  may be with a physically different card reader system  400  or the same physical card reader system  400  in accordance with the invention. Note that this embodiment is typically less secure than the embodiment shown in  FIGS. 3   a - b  because it is typically much easier to eavesdrop on communications using inductive fields that proceed from card reader system  400  to smartcard  40 . However, this embodiment is a lower cost solution because it avoids the need for random number generator  330  in smartcard  40 . 
     While the invention has been described in conjunction with specific embodiments, it is evident to those skilled in the art that many alternatives, modifications, and variations will be apparent in light of the foregoing description. Accordingly, the invention is intended to embrace all other such alternatives, modifications, and variations that fall within the spirit and scope of the appended claims.