US20090028337A1 - Method and Apparatus for Providing Security in a Radio Frequency Identification System - Google Patents

Method and Apparatus for Providing Security in a Radio Frequency Identification System Download PDF

Info

Publication number
US20090028337A1
US20090028337A1 US11/968,002 US96800207A US2009028337A1 US 20090028337 A1 US20090028337 A1 US 20090028337A1 US 96800207 A US96800207 A US 96800207A US 2009028337 A1 US2009028337 A1 US 2009028337A1
Authority
US
United States
Prior art keywords
tag
digital certificate
secure access
iso
security
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.)
Abandoned
Application number
US11/968,002
Inventor
Igor V. Balabine
Nikola Cargonja
Allan M. Evans
Liping Julia Zhu
Devendra Shiledar
Stephen Alan Stough
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Savi Technology Inc
Original Assignee
Savi Technology Inc
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 Savi Technology Inc filed Critical Savi Technology Inc
Priority to US11/968,002 priority Critical patent/US20090028337A1/en
Assigned to SAVI TECHNOLOGY, INC. reassignment SAVI TECHNOLOGY, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZHU, LIPING JULIA, BALABINE, IGOR V., EVANS, ALLAN M., SHILEDAR, DEVENDRA, STOUGH, STEPHEN ALAN, CARGONJA, NIKOLA
Priority to EP08796353A priority patent/EP2181536A2/en
Priority to CN200880107247A priority patent/CN101803334A/en
Priority to KR1020107003578A priority patent/KR20100035712A/en
Priority to PCT/US2008/070614 priority patent/WO2009015073A2/en
Publication of US20090028337A1 publication Critical patent/US20090028337A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06KGRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/0723Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips the record carrier comprising an arrangement for non-contact communication, e.g. wireless communication circuits on transponder cards, non-contact smart cards or RFIDs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0471Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying encryption by an intermediary, e.g. receiving clear information at the intermediary and encrypting the received information at the intermediary before forwarding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0492Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload by using a location-limited connection, e.g. near-field communication or limited proximity of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101Access control lists [ACL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105Multiple levels of security

Definitions

  • This invention relates in general to radio frequency identification systems and, more particularly, to techniques for protecting information in radio frequency identification systems.
  • RFID systems are used in a variety of different applications.
  • RFID systems are commonly used to track and monitor shipping containers or other objects.
  • RFID tags are attached to the containers or other objects, and can exchange wireless communications with stationary interrogators.
  • ISO International Organization for standardization
  • the ISO 18000-7 standard Although the ISO 18000-7 standard been very beneficial, it offers little in the way of security for information. For example, the standard does not allow wireless messages to be encrypted, nor does it have any built-in extension mechanism that would permit the definition of proprietary messages within the protocol, such as proprietary messages with security provisions. Consequently, information transmitted in wireless messages under the ISO 18000-7 standard is fully visible to any entity that elects to receive the wireless messages. A third party may be able to emulate or interfere with ISO 18000-7 messages in various different ways. Consequently, while the ISO 18000-7 standard has been adequate and beneficial for its intended purposes, it has not been entirely satisfactory in all respects.
  • FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system, and that embodies aspects of the present invention.
  • RFID radio frequency identification
  • FIG. 2 is a block diagram of a conventional RFID system in which an interrogator and a tag exchange wireless communications conforming to an industry standard known as ISO 18000-7.
  • FIG. 3 is a diagram showing a data format used within the ISO 18000-7 standard.
  • FIG. 4 is a diagram showing a highly-generalized message format used under the ISO 18000-7 standard.
  • FIG. 5 is a block diagram showing a portion of the system of FIG. 1 , and showing selected aspects of computer programs executed by some of the depicted components.
  • FIG. 6 is a diagram showing in more detail certain information maintained and used in the system of FIG. 5 .
  • FIG. 7 is a table showing examples of five protection suites used within the system of FIG. 5 , each protection suite being a combination of an encryption technique and an authentication technique.
  • FIG. 8 is a diagram showing how an ISO 18000-7 message is compressed, encrypted and fragmented for purposes of transmission within the system of FIG. 5 .
  • FIG. 9 shows a data storage format that is used for certain cryptographic information within the system of FIG. 5 .
  • FIG. 10 is a diagram showing four ISO 18000-7 envelope messages that can be used in the system of FIG. 5 to transmit fragments of another ISO 18000-7 message.
  • FIG. 11 is a diagram similar to FIG. 10 , but showing four ISO 18000-7 envelope messages of a different type.
  • FIG. 12 is a diagram showing an ISO 18000-7 message 501 that is used within the system of FIG. 5 to send separately protected segments of universal data block (UDB) information to respective different recipients.
  • UDB universal data block
  • FIG. 13 is a flowchart showing part of a procedure used to initialize an RFID tag in the system of FIG. 5 .
  • FIG. 14 is a diagram showing three different sites that are geographically spaced from each other, and that each utilize an RFID system of the type shown in FIG. 5 .
  • FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system 10 , and that embodies aspects of the present invention.
  • the system 10 includes two interrogators 12 and 13 , an RFID tag 16 , and a network 18 .
  • FIG. 1 also shows several users 21 - 24 that can each use or interact with the system 10 .
  • a user may be an individual, an entity, a computer, or some other automated device.
  • FIG. 1 is not intended to depict the entire RFID system. For example, the system actually includes a plurality of the tags 16 , and more interrogators than just the two that are shown at 12 and 13 .
  • FIG. 1 shows only selected portions of the RFID system that facilitate an understanding of the present invention.
  • the tag 16 is a mobile, battery-operated device, and can communicate in a wireless manner with each of the interrogators 12 and 13 , in particular by exchanging radio frequency (RF) wireless signals 28 .
  • RF radio frequency
  • all of the wireless signals 28 conform to an existing international industry standard known as ISO 18000-7.
  • ISO 18000-7 This international standard was promulgated by the International Organization for Standardization (ISO), headquartered in Geneva, Switzerland. Persons skilled in the art are familiar with the ISO 18000-7 standard.
  • ISO International Organization for Standardization
  • the term “ISO” is used as a shorthand way to refer to the ISO 18000-7 standard, and should be understood to be a reference to the ISO 18000-7 standard, rather than a reference to the ISO organization itself.
  • the circuitry within the tag 16 includes a processor 41 that is coupled to a memory 42 .
  • the memory 42 in FIG. 1 is a diagrammatic representation of two or more different types of memory, including but not limited to read-only memory (ROM), random access memory (RAM), and flash memory.
  • the memory 42 contains a program 43 that is executed by the processor 41 , and data 44 that is utilized by the program 43 .
  • the circuitry of the tag also includes a serial port 51 , through which a not-illustrated external computer or other device can communicate serially with the processor 41 .
  • the tag 16 has an internal clock circuit 52 with a not-illustrated oscillator, allowing the tag 16 to maintain a record of the current date and time.
  • the circuitry of the tag further includes a radio frequency (RF) receiver 46 that is coupled to the processor 41 and to an antenna 47 .
  • the processor 41 can receive wireless signals 28 through the antenna 47 and receiver 46 .
  • the tag also includes an RF transmitter 48 that is coupled to the processor 41 and to an antenna 49 .
  • the processor 41 can transmit wireless signals 28 through the transmitter 48 and the antenna 49 .
  • the interrogator 13 is a portable, battery-operated, handheld device that can be manually operated by a user 24 who is an individual.
  • the circuitry in the interrogator 13 includes a processor 56 that is coupled to a memory 57 .
  • the memory 57 is a diagrammatic representation of various different types of memory, including but not limited to ROM, RAM and flash memory.
  • the memory 57 contains a program 58 that is executed by the processor 56 , as well as data 59 that is used by the program 58 .
  • the interrogator 13 includes an RF transmitter 61 that is coupled to the processor 56 and to an antenna 62 .
  • the processor 56 can transmit wireless signals 28 through the transmitter 61 and the antenna 62 .
  • the interrogator also includes an RF receiver 63 that is coupled to the processor 56 and to an antenna 64 .
  • the processor 41 can receive wireless signals 28 through the antenna 64 and the receiver 63 .
  • the handheld interrogator 13 further includes a keypad 66 that is coupled to the processor 56 . The user 24 can manually operate the keypad 66 in order to enter information into the interrogator 13 .
  • the interrogator 12 includes a site manager 71 and a reader 72 that are operatively coupled at 73 .
  • the coupling 73 between the site manager 71 and reader 72 is hardwired rather than wireless, and in particular is a network that may conform to a well-known network protocol known as the Ethernet protocol.
  • the site manager 71 and reader 72 could be coupled in any other convenient manner, and could even communicate using wireless signals.
  • FIG. 1 shows only a single reader 72 .
  • the wireless signals 28 conform to the ISO 18000-7 industry standard, and the discussion below will focus to some extent on this industry standard.
  • the site manager 71 and reader 72 are separate and independent devices that are physically and functionally distinct.
  • the ISO 18000-7 standard basically recognizes two general categories of devices, one of which is tags, and the other of which is interrogators. Therefore, for simplicity and clarity in the discussion that follows, the site manager 71 and the reader 72 are collectively referred to herein as an interrogator 12 .
  • the reader 72 is considered herein to be essentially a pass-through device, which facilitates the exchange of ISO messages 28 between the site manager 71 and the tag 16 , but without making substantive alterations to any of the messages traveling in either direction.
  • the reader 72 includes a circuit 76 .
  • An RF transmitter 81 is coupled to the circuit 76 , and to an antenna 82 .
  • the circuit 76 can transmit wireless signals 28 through the transmitter 81 and the antenna 82 .
  • An RF receiver 83 is coupled to the circuit 76 and to an antenna 84 .
  • the circuit 76 can receive wireless signals 28 through the antenna 84 and the receiver 83 .
  • the site manager 71 includes a processor 86 that is coupled to a memory 87 .
  • the memory 87 is a diagrammatic representation of various different types of memory, including but not limited to ROM, RAM and flash memory.
  • the memory 87 stores a program 88 that is executed by the processor 86 , and also stores data 89 that is used by the program 88 .
  • the user 21 can interact with the site manager 71 .
  • the site manager 71 may include a not-illustrated terminal, and the user 21 may be an individual who interacts with the site manager through that terminal.
  • the network 18 is operatively coupled to a network port of the site manager 71 .
  • the network 18 may include one or more of the Internet, an intranet, some other type of computer network, or a combination of two more such networks.
  • the users 22 and 23 can communicate with the site manager 71 through the network 18 .
  • the users 22 and 23 may, for example, be individuals who are using personal computers or other terminals that are coupled to the network 18 .
  • the users 22 and 23 may be automated systems that are operatively coupled to the network 18 .
  • the user 22 could be a site manager that is similar to the site manager 71 , but that is located in a different site at a physically remote location.
  • the tag 16 and the interrogators 12 and 13 each include both hardware and software (where the software may include firmware).
  • the hardware in the interrogators 12 and 13 and in the tag 16 is entirely conventional.
  • the new and unique characteristics discussed herein are embodied in the software, including the programs 43 , 58 and 88 executed by the various processors in the tag 16 and interrogators 12 and 13 .
  • the new and unique characteristics in the program 88 of the interrogator 12 are essentially the same as those in the program 58 of the interrogator 13 .
  • FIG. 2 is a block diagram of a system 10 A that includes an interrogator 12 A and a tag 16 A that can exchange wireless communications 28 conforming to the ISO 18000-7 standard.
  • components that are the same as or similar to components in FIG. 1 are identified with the same or similar reference numerals.
  • the hardware of the interrogator 12 A of FIG. 2 is identical to the hardware of interrogator 12 of FIG. 1 , and that the differences between these interrogators reside in the computer programs within them.
  • the hardware of the tag 16 A of FIG. 2 is identical to the hardware of the tag 16 of FIG. 1 , and that the differences between these tags reside in the computer programs within them.
  • the subject matter depicted within the interrogator 12 and within the tag 16 represents primarily a high-level view of their hardware configurations.
  • the subject matter depicted within the interrogator 12 A and within the tag 16 A represents selected high-level aspects of the computer programs within the interrogator 12 A and tag 16 A.
  • the computer program in the interrogator 12 A includes an application program 101 .
  • the data maintained by the application program 101 includes an interrogator identification code 103 that uniquely identifies the particular interrogator 12 A.
  • a given site may include multiple interrogators and multiple tags, such that a given tag may be carrying on communications with more than one interrogator, and a given interrogator may be carrying on communications with more than one tag. Accordingly, when the interrogator 12 A transmits a wireless ISO message at 28 , the interrogator includes in the message its interrogator identification code 103 , so that any tag receiving that message will know which particular interrogator sent the message.
  • the computer program executed in the tag 16 A includes an application program 111 .
  • the application program 111 maintains a database of ISO tables 116 , and examples of two ISO tables are shown diagrammatically at 117 and 118 .
  • the application program 111 includes a segment of user memory 121 , and maintains a tag manufacturer identification code 122 that uniquely identifies the company that manufactured the tag 16 A.
  • the application program 111 also maintains a tag model number 123 corresponding to the tag 16 A, and a tag serial number 124 that is unique to the particular tag 16 A.
  • the application program 111 further maintains a user-assigned identification code 125 that can be set and/or read by an external user, such as one of the users 21 - 23 .
  • the application program 111 maintains a routing code 126 .
  • the routing code 126 may be a code that identifies the particular shipping route.
  • the application program 111 also contains a firmware revision number 127 identifying the particular version of the software/firmware computer program that is currently installed in the tag 16 A.
  • the application program 111 maintains a tag password 128 . If password protection in the tag is enabled, and if one of the users 21 - 23 wishes to communicate with the tag, then the user will first need to supply the tag with the correct password.
  • FIG. 3 is a diagram showing one common data format 141 that is used within ISO 18000-7 messages.
  • This data format 141 includes three fields, which are a type or “T” field 142 , a length or “L” field 143 , and a value or “V” field 144 . Combining the first letters of the names of these fields yields the acronym “TLV”, and thus the data format 141 is commonly referred to as the “TLV” format.
  • the type field 142 contains a code that uniquely identifies the type of data present in the value field 144 .
  • the length field 143 defines the length the value field 144 , and in particular contains a number that represents the number of bytes present in the value field 144 .
  • the value field 144 contains one or more data elements (and each such data element may itself also have the TLV format). Persons skilled in the art are thoroughly familiar with the TLV data format shown in FIG. 3 .
  • FIG. 4 is a diagram showing a highly-generalized format 151 that is used for many types of ISO messages under the ISO 18000-7 standard.
  • the message format 151 includes a section 153 of ISO headers, which is a collection of several different fields. The particular set of fields that are present at 151 will vary somewhat from message to message. For example, the ISO headers 153 always include a not-illustrated protocol identification field.
  • the ISO headers 153 will typically also include the interrogator identification code 103 ( FIG. 2 ) when the message is being transmitted by the interrogator 12 A, but not if the message is transmitted by the tag 16 A. Conversely, the ISO headers 153 will typically include the tag serial number 124 ( FIG. 2 ) if the message is being transmitted by the tag 16 A, but not if the message is being transmitted by the interrogator 12 A. There are other fields that can also be present in the ISO headers 153 , but since they are well known in the art, they are not all discussed in detail here.
  • the format 151 also includes a command code 154 to tell a receiving device what it is expected to do, a field 155 containing data and/or arguments for the command code 154 , and an error checking field 156 .
  • the error checking field 156 typically contains a cyclic redundancy code (CRC) of a known type.
  • Table 1 gives examples of some commands that the interrogator 12 A of FIG. 2 can send to the tag 16 A. It will be noted that some of these commands allow the interrogator 12 A to read or write the user-assigned identification code 125 ( FIG. 2 ), the routing code 126 , or the user memory 121 . Other commands allow the interrogator 12 A to read the firmware revision number 127 , or the tag model number 123 . Still other commands allow the interrogator 12 A to change the tag password 128 , and to engage or disengage password protection. Still other commands allow the interrogator 12 A to create a table within the database 116 of ISO tables, to write information into a table, or to read information from a table.
  • Another command instructs the tag to enter a low-power “sleep” mode in which most (but not all) of the circuitry in the tag is turned off in order to conserve battery power. Still another command turns on or off a not-illustrated audible beeper that is located within the tag.
  • Table 1 does not list all of the commands that exist under the ISO 18000-7 standard, but merely gives examples of some of those commands.
  • messages that are sent from the interrogator 12 A to the tag 16 A and that involve security fall generally within one of three different categories.
  • the interrogator 12 A can select any one of the tags and send a message specifically to that one particular tag, and then expect a single response from that tag.
  • This type of message is known as a Point-2-Point or “P2P” message.
  • the interrogator 12 A can broadcast a single message to all of the security-enabled tags that are currently within the wireless transmission range of that particular interrogator.
  • the interrogator can send one or more ISO “table query” broadcast messages to multiple tags, followed by an ISO collection query broadcast message. The interrogator then expects a single separate response from each individual tag. Messages in this category are referred to in this discussion as table query broadcast messages.
  • a third category of ISO messages is referred to as universal data block or “UDB” collection.
  • the interrogator 12 A can broadcast to multiple tags a common message that instructs each tag to formulate and send back a UDB data block.
  • Each tag then prepares a UDB data block that has a predefined format, and that typically contains multiple items of data.
  • the UDB data block may include tag identification information (discussed in more detail later), and/or a routing code. Under proprietary extensions, various other data items could also be present.
  • the various data elements in the UDB are typically each presented in the TLV format discussed above in association with FIG. 3 . After each tag has prepared its UDB, the tag sends its UDB back to the interrogator 12 A in a wireless message 28 that conforms to the ISO 18000-7 standard.
  • a third-party device can emulate an interrogator and communicate with the tag 16 A.
  • the tag will not know that it is communicating with an imposter rather than an actual valid interrogator. If the tag currently has password protection disabled, the third party device will be able to read or write data present within the tag, possibly in support of a fraudulent purpose.
  • a valid interrogator happens to send the tag 16 A a message that includes the current password for the tag
  • a third-party device can receive the message and learn the password. Using the password, the third-party device will have full read and write access to the tag.
  • the third-party device could even replace the current password with a new password, thereby preventing a valid interrogator from subsequently communicating with the tag.
  • one aspect of the present invention involves the provision of a high level of security for information exchanged between an interrogator and a tag, while still remaining fully compatible with the existing ISO 18000-7 standard.
  • FIG. 5 is a block diagram showing a selected portion of the system 10 of FIG. 1 , including the interrogator 12 , the tag 16 , the network 18 and the users 21 - 23 .
  • the subject matter depicted in FIG. 1 within the interrogator 12 and within the tag 16 represents primarily a high-level view of their hardware configurations.
  • the subject matter depicted within the interrogator 12 and the tag 16 represents selected high-level aspects of the computer programs within the interrogator and tag.
  • FIG. 5 is similar in some respects to FIG. 2 .
  • the firmware of the interrogator 12 includes the conventional application program 101 that was discussed above in association with FIG.
  • the firmware in tag 16 includes the conventional application program 111 that was discussed above in association with FIG. 2 .
  • the primary difference between FIG. 5 and FIG. 2 is that in FIG. 5 the firmware in the interrogator 12 includes an additional module in the form of a security shim 201 , and the firmware in the tag 16 includes an additional module in the form of a security shim 202 .
  • the security shim 201 is disposed between the application program 101 and the wireless messages 28 that are exchanged between the interrogator 12 and the tag 16 .
  • the security shim 202 is conceptually disposed between the application program 111 and the wireless messages 28 . If the application program 101 in the interrogator 12 wishes to securely transmit an ISO message to the application program 111 in the tag 16 , the security shim 201 takes that ISO message, uses encryption and authentication techniques to add a level of security, and then sends a wireless message at 28 that contains the encrypted message with authentication information, while being fully compliant with ISO 18000-7. The security shim 202 in the tag then uses decryption to recover the original ISO message, and delivers that message to the application program 111 .
  • the security shim 202 uses encryption to add a level of security, and then transmits a wireless message at 28 that contains the encrypted message but is fully ISO 18000-7 compliant.
  • the security shim 201 in the interrogator then uses decryption to recover the ISO message, and delivers that message to the application program 101 .
  • the security shims 201 and 202 are effectively transparent to the application programs 101 and 111 . Moreover, even though the ISO messages exchanged at 28 in FIG. 5 differ in some respects from the messages that would be exchanged if the security shims 201 and 202 were not present, the messages exchanged at 28 are nevertheless all fully compliant with ISO 18000-7. Thus, the security shims 201 and 202 are transparent from the perspective of ISO compliance, because the messages 28 do not violate any of the requirements of the ISO 18000-7 standard.
  • the security shim 202 maintains a security officer access control list 211 .
  • the list 211 will include at least one security officer access control object 210 that in turn includes a digital certificate 212 known as the “root” certificate.
  • the root certificate 212 contains a PKI public key 213 .
  • the certificate 212 is a type of digital certificate conforming to an industry standard that is known as the X.509 standard, promulgated by the International Telecommunication Union (ITU) based in Geneva, Switzerland. Since this type of X.509 certificate is known in the art, it is not described here in detail.
  • the access control object 210 includes tag access information 214 that defines the level of access that will be permitted to the tag 16 through use of the associated X.509 certificate.
  • the tag access information 214 can be viewed as a set of rules that govern access to the tag.
  • the security scheme implemented by security shims 201 and 202 recognizes four distinct levels of access to a tag, which are listed in Table 2.
  • TABLE 2 ROLE DESCRIPTION Tag Owner Installs on tag the access control object containing the root certificate, and distributes corresponding certificates to security officer(s).
  • Security Officer Can provision cryptographic keysets on tag, and distribute them to authorized persons and entities.
  • Administrator Receives keysets that allow read-only and also read/write access to tag.
  • Operator Receives keysets that allow just read-only access to tag.
  • the lowest level of access is that of an “operator”, who has only read-only access to information on the tag.
  • the next higher level of access is that of an “administrator”, who has read-only access, and also read/write access.
  • the next higher level is that of a “security officer”, who can take security-related actions in the tag that will be described later, such as creating cryptographic keysets, and installing and removing digital certificates (other than the root certificate 212 ).
  • the highest level of access is that of the tag owner, who has the power to install and remove the access control object 210 containing the root certificate 212 . This may, for example, be effected through the serial port 51 , as indicated diagrammatically by a broken line 216 . IN fact, the overall degree of security is enhanced where operators, administrators and security officers carry out secure communications in one manner (for example through wireless communications), while the access control object 210 containing the root certificate 212 is installed in a different manner (for example through the serial port 51 ).
  • the tag access information at 214 indicates the maximum levels of access that can be obtained with the associated digital certificate 212 .
  • the tag access information 214 indicates whether the associated digital certificate can be used to create keysets for read-only access, and whether the associated certificate can be used to create keysets for read/write access.
  • the root certificate 212 it will normally be permissible to create keysets for read-only access and keysets for read/write access. This does not mean that everyone obtaining access with keysets created under this certificate will necessarily enjoy full access. For example, as discussed above in regard to Table 2, a person using operator keysets created under this certificate will be limited to read-only access, even if the tag access information indicates that read/write access is permissible.
  • the tag access information 214 indicates that read/write access is not permitted, then it will not be possible to create keysets under the associated certificate that would provide read/write access.
  • a security officer using a security officer keyset created under one certificate can optionally install one or more additional access control objects in the list 211 , for example as shown at 220 .
  • the tag access information for one of these other access control objects might indicate that creation of read-only keysets under the associated certificate 221 is permitted, but that creation of read/write keysets under that further certificate is prohibited. If a security officer is using a security officer keyset created under an existing certificate in an existing access control object, and installs a further access control object, the tag access rights for that further object must not exceed the tag access rights in the existing object under which the security officer keyset was created.
  • the security shim 202 also maintains a further list 226 that is a universal data block (UDB) recipient list.
  • the list 226 may be empty, or may optionally contain one or more UDB access control objects.
  • reference numeral 227 designates a UDB access control object containing a digital certificate 225 of a UDB recipient.
  • the UDB certificate 225 is an X.509 certificate, and contains a PKI public key 228 .
  • the UDB access control object 227 further includes UDB access information 229 .
  • the list 226 may optionally include a second UDB access control object 231 containing a digital certificate 230 with a public key 232 , and UDB access information 233 .
  • the UDB access information 229 and the UDB access information 233 can each be viewed as a set of rules that govern access to UDB information, as discussed below.
  • the UDB access control objects in the list 226 identify the persons or entities who will be the ultimate recipients of the tag's UDB information.
  • the application program 111 in the tag 16 collects all of the UDB information that is present within the tag.
  • the security shim 202 in the tag intercepts this UDB information from the application program 111 , uses the UDB access control objects in the list 226 to identify UDB recipients, and prepares a respective separate block of UDB data for each UDB recipient identified by the UDB access control objects 227 and 231 in the list 226 .
  • the security shim 202 does not necessarily pass all of the UDB information on to each of the recipients identified by the respective access control objects in the list 226 . Instead, the UDB access information 229 or 233 in each access control object defines which items of UDB information will be received by the associated recipient.
  • FIG. 6 is a diagram showing the UDB access information 229 associated with the UDB access control object 227 , and also the UDB access information 233 associated with the UDB access control object 231 .
  • the UDB access information 229 associated with access control object 227 indicates the associated recipient is permitted to receive each of data elements Data 1 , Data 2 , and Data N (and possibly other UDB data elements that are between Data 2 and Data N).
  • the access information 233 associated with access control object 231 indicates the associated recipient is entitled to receive data element Data 1 (and possibly other data elements between Data 2 and Data N), but not data element Data 2 or data element Data N.
  • the security shim 202 also maintains UDB protection status information 241 .
  • This information identifies the data elements in the tag's UDB information that will be protected by encryption and authentication, and the data elements that will not be protected.
  • the UDB protection status information 241 is depicted twice, once in association with UDB access information 229 , and again in association with UDB access information 233 .
  • the UDB protection status information 241 indicates that data elements Data 2 and Data N will be protected, but that data element Data 1 will not be protected.
  • the security shim 202 Since the UDB access information 229 indicates that the associated recipient is entitled to receive each of data elements Data 1 , Data 2 and Data N, then when the security shim 202 receives UDB information from the application program 111 (including data elements Data 1 through Data N),the security shim 202 will formulate a UDB block for that recipient which includes each of Data 1 , Data 2 and Data N (and possibly other data elements between Data 2 and Data N). Further, since UDB protection status 241 indicates that Data 2 and Data N need to be protected, the security shim 202 would encrypt data elements Data 2 and Data N. More specifically, the security shim 202 would generate a random key, use the random key to separately encrypt each of Data 2 and Data N, and then encrypt the random key with that recipient's public key 228 .
  • the security shim 202 since the UDB access information 233 for the other UDB access control object 231 indicates that the associated recipient is entitled to receive data element Data 1 but not data elements Data 2 and Data N, then when the security shim 202 receives UDB information from the application program 111 , the security shim 202 will formulate a UDB block for that recipient which includes Data 1 (and possibly other data elements between Data 2 and Data N), but not data elements Data 2 and Data N.
  • the UDB protection status information 241 indicates that data elements Data 2 and Data N need to be protected, but this recipient is not receiving those data elements. This recipient is receiving data element Data 1 , but the UDB protection status information 241 indicates that data element Data 1 does not need to be protected. Therefore, data element Data 1 would not be encrypted.
  • the application program 111 maintains a database 116 of ISO 18000-7 tables, and examples of two of these tables are shown at 117 and 118 .
  • the security shim 202 maintains a database 249 of three virtual ISO tables, which are a P2P Request Table 251 , a P2P Response Table 252 , and a Broadcast Request Table 253 . These are referred to as virtual tables, because the application program 111 of the tag is not aware they exist.
  • There are standard ISO commands that can be used to access ISO tables in the database 116 and the security shim 201 can use these same standard ISO commands to access the virtual ISO tables 251 - 253 , as discussed in more detail later.
  • the security techniques used by the security shims 201 and 202 involve both (1) a cryptographic technique used to encrypt and decrypt information, and (2) an authentication technique used to authenticate information received in wireless ISO messages 28 .
  • the security shims 201 and 202 are each capable of working with any of several different cryptographic techniques, and with any of several different authentication techniques.
  • a combination of one particular encryption technique and one particular authentication technique is referred to herein as a “protection suite”.
  • the security shim 202 maintains a list 258 of the protection suites with which it is compatible.
  • FIG. 7 is a table showing examples of five protection suites, which are the protection suites with which the security shim 202 is compatible.
  • protection suite list 258 in the security shim 202 will always include the NULL-NULL protection suite, along with at least one other protection suite.
  • the security shim 202 maintains a keyset table 270 that can store four different cryptographic keysets 271 - 274 .
  • the keyset 271 is a security officer (SO) keyset that can be used by a security officer when reading information from or writing information to the tag 16 .
  • the keyset 271 can be said to be bidirectional, in that it can be used for messages sent to the tag and also messages sent by the tag.
  • the keyset 272 is a read-only keyset, and is used for messages that are sent to the tag by anyone other than a security officer, and that do not seek to change any information within the tag.
  • the keyset 272 is unidirectional, in that it is used only for messages sent to the tag, and not for any messages sent by the tag.
  • the keyset 273 is a read/write keyset, and can be used for messages that are sent to the tag by anyone other than a security officer, and that seek to change information within the tag.
  • the keyset 273 is unidirectional, in that it is used only for messages sent to the tag, and not for any messages sent by the tag.
  • the keyset 274 is a tag response keyset, and is used for messages sent by the tag to anyone other than a security officer.
  • the keyset 273 is unidirectional, in that it is used only for messages sent by the tag, and not for any messages sent to the tag.
  • a person or entity with operator status would be given the read-only keyset 272 and also the tag response keyset 274 .
  • a person or entity with administrator status would be given the read-only keyset 272 , the read/write keyset 273 , and the tag response keyset 274 .
  • a security officer would use the security officer keyset 271 to carry out certain tasks specific to security officers.
  • Table 3 is an expanded version of Table 1, showing examples of some ISO commands for which the read-only keyset 272 is used, and examples of other ISO commands for which the read/write keyset 273 is used.
  • the commands in Table 3 are merely exemplary, because Table 3 does not show all ISO commands.
  • the tag replies to any command in Table 3 the tag would use the tag response keyset 274 .
  • FIG. 5 shows only a single interrogator 12 and a single tag 16 , but it is possible for the tag 16 to carry on communications with more than one interrogator at the same time.
  • the security shim 202 in the tag 16 maintains a table 279 that contains a record for each interrogator with which the tag is currently communicating. Each such interrogator is identified in the left column of the table by its interrogator identification code 103 . For each such interrogator, the right column of the table 279 contains a sequence number. In this regard, any given interrogator may transmit a series of ISO wireless messages to the tag 16 , and each of these messages will contain a sequence number, as discussed later.
  • the table 279 contains the sequence number from the message most recently received from that interrogator.
  • the security shim 202 checks to see whether the sequence number in the new message is greater than the sequence number currently stored in the table 297 for that interrogator. If the sequence number from the new message is equal to or less than the number in the table, then the security shim flags an error. Otherwise, the security shim accepts the new message, and replaces the sequence number in the table 279 with the sequence number from the new message.
  • FIG. 5 shows that the security shim 201 includes security officer credentials 300 , the credentials 300 including a security officer (SO) certificate 301 containing a public key 302 , and a private key 303 .
  • the SO certificate 301 corresponds to the root certificate 212 in the tag 16 .
  • the public key 302 in the credentials 300 was generated by concatenating the public key 213 of the root certificate 212 with a public key corresponding to the private key 303 in the credentials 300 , and then signing the two concatenated keys with a not-illustrated private key corresponding to the public key 213 .
  • the credential 300 can be introduced into the interrogator 12 from a portable memory device 306 of a known type, such as a Universal Serial Bus (USB) flash memory device, or a device of the type commonly known as a “smartcard”.
  • a portable memory device 306 of a known type, such as a Universal Serial Bus (USB) flash memory device, or a device of the type commonly known as a “smartcard”.
  • USB Universal Serial Bus
  • a protection suite is a combination of one particular encryption technique and one particular authentication technique.
  • the security shim 201 includes a list 311 of protection suites with which it is compatible.
  • This protection suite list 311 is conceptually similar to the protection suite list 258 discussed earlier in association with the security shim 202 and FIG. 7 .
  • the set of protection suites identified in the list 311 may not necessarily be identical to the set of protection suites identified in the list 258 .
  • both lists will include the NULL-NULL protection suite ( FIG. 7 ), as well as at least one other protection suite.
  • the lists 258 and 311 will need to have at least one protection suite in common (other then the NULL-NULL protection suite).
  • the security shim 201 can generate and temporarily save a transient PKI public key 316 and a corresponding transient PKI private key 317 , for a purpose discussed in more detail later.
  • the security shim 201 also includes encrypted storage 326 that may be empty, but that will typically include one or more keyset tables, two examples of which are shown at 327 and 328 .
  • the keyset tables 327 and 328 are each similar to the keyset table 270 discussed above, which contains four keysets 271 - 274 .
  • the keyset table 327 is for the tag 16 and is thus identical to the keyset table 270 in the tag 16
  • the keyset table 328 corresponds to a different tag and thus is not identical to the keyset table 270 in tag 16 .
  • the keyset tables 327 and 328 may each contain a read-only keyset that is identical to the read-only keyset 272 in the tag 16 .
  • the encryption technique used for protecting the storage 326 is implemented with the Microsoft® Cryptographic API (CAPI) available on the Windows XP® and Windows CE® platforms (CE-CRYPTO).
  • the encryption could alternatively be implemented using any other suitable encryption platform.
  • the storage 326 is encrypted.
  • the security shim 201 maintains an access control section 336 that contains one or more access control blocks each corresponding to a respective different user.
  • the control section 336 contains an access control block 341 that has a user identification 342 , a password 344 , and an identification 343 of one or more keyset tables 327 - 328 that the specified user is authorized to use.
  • another access control block 346 has a user identification 347 that identifies a different user, a password 349 for that user, and an identification 348 of one or more keyset tables 327 - 328 that the user is authorized to use.
  • each keyset table identified at 343 is obtained from encrypted storage 326 , decrypted, and then made available for use by that user. Each user is permitted to freely change his or her password.
  • the security officer credentials 300 could also be maintained in protected storage, with access thereto controlled by the access control section 336 .
  • the ISO 18000-7 standard does not have any provision for protecting ISO messages that are being transmitted. Moreover, this ISO standard does not have a built-in extension mechanism permitting the definition of new and proprietary messages that conform to the standard but that could also use encryption or some other security mechanism. Accordingly, the security shims 201 and 202 implement a unique technique that complies with the ISO 18000-7 standard but that provides strong security for ISO messages exchanged between the application program 101 in the interrogator and the application program 111 in the tag 16 . According to this technique, the actual original ISO 18000-7 message is encrypted, then transmitted as a payload within at least one other ISO 18000-7 message that is not encrypted and that effectively serves as an envelope for the encrypted original message. This approach of embedding one ISO message within another is referred to herein as “tunneling” the encrypted message within the envelope message.
  • the ISO 18000-7 standard includes commands that permit the interrogator 12 of FIG. 5 to access ISO tables in the database 116 , such as the exemplary tables shown at 117 and 118 .
  • the security shim 201 of the interrogator 12 uses the same ISO table commands for envelope messages, in order to access the virtual tables 251 - 253 in the security shim 201 .
  • the security shim 201 intercepts this ISO message, adds encryption and authentication, and then transmits it as the payload in at least one enveloping ISO message containing a table write fragment command directed to one of the virtual tables 251 or 253 .
  • the encrypted and authenticated command will usually be too large to be sent as the payload of a single ISO message. This is due in part to the fact that, in the United States, the Federal Communications Commission limits RFID infrastructure transmissions to 25 msec out of any 100 msec time window, which effectively limits each message to a length of about 100 bytes. Other countries and local authorities may also impose constraints. Accordingly, since the encrypted and authenticated command will usually be too large to embed within a single ISO message, it will typically be broken into several fragments, and then the fragments will be sent separately to the table 251 or 253 in respective different enveloping messages that are each an ISO table write fragment command.
  • the security shim 202 will retrieve and reassemble the fragments, authenticate and decrypt the result in order to recover the original ISO command, and then deliver this ISO command to the application program 111 .
  • the security shim 202 can intercept this ISO message, add encryption and authentication, fragment the message, and put the fragments into the virtual table 252 .
  • the security shim 202 then notifies the security shim 201 , and the security shim 201 retrieves these fragments from the virtual table 252 using successive ISO table read fragment commands. That is, the fragments are each transported as the payload of a respective envelope ISO message sent in response to an ISO table read fragment command.
  • the security shim 201 When the security shim 201 has retrieved all of the fragments from the table 252 , it reassembles the fragments and then authenticates and decrypts the result, in order to recover the original ISO message. The security shim 201 then delivers the original ISO message to the application program 101 .
  • the virtual tables 251 and 252 are used for P2P messages and responses, and the virtual table 253 is used for broadcast table query messages.
  • FIG. 8 is a diagram showing in more detail how this can be accomplished for an ISO 18000-7 P2P message 401 that is generated by the application program 101 .
  • the command 401 has a standard ISO format, including ISO headers 402 , a command code 403 , a length value 404 , and data 405 .
  • some of the ISO headers 402 from the message 401 are dropped, in order to obtain a compressed version 411 of the ISO headers 402 . This is shown in more detail in Table 4.
  • ACTION HEADERS Header would be the same in both Packet Options the tunneled message and the Tag Manufacturer ID envelope message. Omit from header Tag Serial Number of tunneled message, and then Interrogator ID recreate at receiving end by copying from the equivalent header in the envelope message. Omit from header of tunneled Packet Length message, and then recreate at CRC receiving end by re-computing the value. To protect this information, Tag Status preserve this header in the tunneled message, and set the corresponding header of the envelope message to always indicate a positive response from tag.
  • the ISO headers 402 are retained in the tunneled message, some of them would necessarily always be identical to their counterparts in the ISO headers of the envelope message. Accordingly, these headers are omitted from the tunneled message. At the receiving end, they are added back to the tunneled message by simply copying the counterparts from the envelope message. As shown in Table 4, these include well-known ISO headers such as packet options, tag manufacturer identification, tag serial number, and interrogator identification code. As another example, some of the ISO headers 402 of the tunneled message would not necessarily be identical to their counterparts in the envelope message, but can be omitted from the tunneled message, and then recreated at the receiving end by recomputing them. As shown in Table 4, these include the well-known ISO headers of packet length and CRC error checking.
  • the tag status header is maintained without change in the tunneled message.
  • the counterpart header in the envelope message could be identical.
  • this status information in the header of the envelope message would then be publicly accessible to anyone within the transmission range of the tag.
  • the ISO tag status header in each envelope message is unconditionally set to indicate a positive status response from the tag, regardless of whether the tag status header in the tunneled message happens to be positive or negative. Consequently, other parties who may look at the envelope message will always see it reflecting a positive tag status, and will not know whether the actual tag response was positive or negative.
  • reference numeral 412 identifies the compressed version of the original ISO message 401 .
  • a selected common protection suite will be in effect. As discussed above, that protection suite will identify both an encryption technique and an authentication technique. In addition, between that same pair of devices, it will be possible to identify an appropriate cryptographic keyset which, depending on the circumstances, may be the security officer keyset 271 , the read-only keyset 272 , the read/write keyset 273 , or the tag response keyset 274 .
  • the compressed ISO message 412 is encrypted using the appropriate keyset and using the encryption technique specified in the selected protection suite (unless the suite specifies NULL rather than an encryption technique).
  • the resulting encrypted information 416 is expressed in TLV format.
  • a cryptographic information TLV 417 is concatenated to the encrypted information TLV 416 .
  • the cryptographic information TLV is not itself encrypted, but indicates how the information 416 was encrypted, including an identification of the particular protection suite used and the particular keyset used.
  • FIG. 9 is an example of how the cryptographic information TLV 417 would appear if the selected protection suite was the AES-128-CTR-HMAC-SHA1-96 suite of FIG. 7 .
  • the cryptographic information TLV 417 and the encrypted information TLV 416 represent the protected payload 421 that is to be transmitted. This payload will usually be too long to be sent in a single ISO envelope message. Therefore, the protected payload 421 is typically fragmented in a way that minimizes the number of fragments that must be separately sent.
  • FIG. 10 is a diagram showing four ISO envelope messages 436 - 439 , each of which contains a table write fragment command directed to the virtual table 251 in FIG. 5 .
  • the ISO messages 436 - 438 each include a respective one of the fragment TLVs F 1 , F 2 , and F 3 .
  • the fourth ISO message 439 contains a TLV 441 with authentication information.
  • the authentication information 441 includes a sequence number, and also a checksum value that will be explained later.
  • the original ISO message 401 ( FIG. 8 ) contains a sequence number. This sequence number from the original ISO message 401 is the sequence number in the authentication information 441 of the ISO message 439 .
  • the security shim 201 of the interrogator 12 transmits to the tag 16 a not-illustrated ISO table update record command, which serves as a request for permission to update the table 251 .
  • the security shim 202 of the tag 16 then sends back an ISO message containing a value that is commonly referred to as an operation initiation token. This and other similar tokens are random values, which adds to the security of a given message exchange.
  • the interrogator 12 then sends the ISO message 436 in order to put the fragment TLV F 1 in the table 251 , and the tag responds by transmitting an ISO message with an operation continuation token.
  • the interrogator transmits the ISO message 437 , and receives back an ISO message with a further continuation token.
  • the interrogator then transmits the ISO message 438 , and receives back another ISO message with a continuation token.
  • the interrogator then transmits the ISO message 439 .
  • the checksum in the authentication TLV 441 of the message 439 is computed by concatenating all messages that have been exchanged between the interrogator and the tag, beginning with the initial table update record message, and including all messages sent by the tag with continuation tokens, as well as the final message 439 , except for the authentication portion of the final message 439 .
  • This authentication checksum is computed according to the authentication technique indicated in the protection suite identified by the cryptographic information TLV 421 ( FIG. 8 ), and using the appropriate keyset.
  • the security shim 202 in tag 16 takes the sequence number from the authentication information 441 in the final message 439 , and compares that sequence number to the sequence number currently stored in the table 279 for the interrogator 12 . If the sequence number from the message 439 is less than or equal to the sequence number currently stored in the table 279 , the security shim 202 flags an error. Otherwise, the security shim 202 replaces the sequence number in table 279 with the new sequence number from the authentication information in message 439 .
  • the security shim 202 locally computes its own authentication checksum, and compares it to the authentication checksum received in the authentication information 441 of the message 439 , in order to confirm that the checksums are identical. If the tag detects an error at any time during the exchange of messages, then the tag sends the interrogator an ISO 18000-7 error message of a known type. Upon receiving this error message, the security shim 201 in the interrogator 12 discontinues the transmission, and notifies the application program 101 about the error.
  • the security shim 202 in the tag has not identified any errors, and if the authentication checksum is verified successfully, then the security shim 202 (1) reassembles the fragments F 1 , F 2 , and F 3 , (2) decrypts this reassembled information, and (3) replaces or recreates the missing ISO headers, in order to thereby end up with the original message that is shown in 401 at FIG. 8 .
  • the security shim 202 then delivers this ISO message 401 to the application program 111 in the tag 16 .
  • the tag In response to the command in the ISO message 401 , the tag will send a response back to the interrogator. This response is handled in a manner that is only slightly different from the manner described above for the message 401 .
  • the application program 111 in the tag 16 formulates an ISO message containing its response.
  • the security shim 202 compresses the ISO headers, encrypts the result, adds a cryptographic information TLV, and puts the resulting fragment TLVs in the P2P Response Table 252 .
  • the tag then sends the interrogator an ISO message containing a special token that indicates to the security shim 201 in the interrogator that a secure response is ready, and waiting to be retrieved. This prompts the interrogator to read the fragment TLVs from the table.
  • the manner in which this is carried out is known under the ISO 18000-7 standard, and the retrieval of the fragments is therefore described only briefly here.
  • the interrogator In response to the token from the tag, the interrogator sends back an ISO message containing an ISO table get data command, and the tag responds with an operation initiation token that is a random value. The interrogator then sends an ISO table read fragment command to the tag, and the tag sends back an ISO message containing the first fragment and a further random token. The interrogator then requests the next fragment, and so forth. After the tag sends the last actual fragment, and in response to the next table read fragment request from the interrogator, the tag sends an ISO message that contains a sequence number and an authentication checksum.
  • the authentication checksum is computed by concatenating all messages exchanged between the interrogator and tag, beginning with the message containing the initial token sent by the tag upon completing preparation of its response, and ending with the tag's final message containing the authentication checksum, except for the checksum itself.
  • the tag sends the interrogator an ISO 18000-7 error message. The interrogator then discontinues the exchange, and notifies the application program 101 of the error.
  • the interrogator When the interrogator receives the message with the tag's authentication checksum, the interrogator independently computes an authentication checksum, and compares it to the authentication checksum received from the tag, in order to verify that they are identical. If the tag's authentication checksum is verified successfully, then the security shim 201 in the interrogator reassembles the various fragments it retrieved, decrypts the result, and replaces or recreates the missing ISO headers, in order to thereby end up with the ISO message that was the tag's response. The security shim 201 then passes this ISO message to the application program 101 in the interrogator.
  • the foregoing explanation relates to an exchange that began when the interrogator 12 decided to send an ISO P2P message to a single specific tag 16 .
  • the interrogator 12 can also broadcast to a plurality of different tags an ISO 18000-7 broadcast table query message having embedded within it a protected broadcast table query.
  • the embedded message is a table query directed to one of the ISO tables 117 - 118 that is present in each of the tags, and is sent in an envelope message that is a table query to the Broadcast Request Table 253 .
  • the original command is compressed, encrypted and fragmented in a manner similar to that shown in FIG. 8 , with two differences.
  • the first difference is that the encryption is always carried out using the read-only keyset 272 of the tags to which the message is directed. It will be noted that these tags all need to share the same read-only keyset 272 , but the other keysets 271 , 273 and 274 can all be different and unique in each tag.
  • the second difference relates to the compressed ISO headers in the tunneled message.
  • the ISO headers of the tunneled message include a packet options field, which in turn contains a communication type bit.
  • this communication type bit will be a binary “0”, to indicate that the communication is a broadcast communication.
  • the security shim 201 in the interrogator generates a random bit that is referred to here as the collection query random bit “CQRB”.
  • the security shim 201 saves the CQRB for later use, and also stores this bit in the communication type bit of the packet options field in the compressed ISO headers, in place of the binary “0” that the interrogator 12 put there.
  • FIG. 11 is a diagram showing how the fragments of the original table query message are sent in several successive ISO table query messages 446 - 449 that are directed to the Broadcast Request Table 253 in the tags.
  • the transmission of the messages 446 - 449 conforms to the ISO 18000-7 standard, and is therefore discussed here only briefly.
  • the interrogator 12 successively transmits each of the messages 446 - 449 , without receiving any response from any of the multiple tags.
  • the final message 449 contains authentication information 456 , including a final sequence number, and an authentication checksum.
  • the checksum is computed by concatenating all of the information in all of the messages 446 - 449 , except for the checksum itself.
  • the checksum is computed according to the message authentication algorithm of the protection suite identified in the cryptographic information TLV that is embedded within the fragment F 1 in the first message 446 , using the read-only keyset 272 .
  • the tag's security shim 202 monitors the ISO 18000-7 query collection command sequence numbers in those messages, using the table 279 ( FIG. 5 ). In particular, if a received sequence number is less than or equal to the sequence number currently stored in the table 279 for interrogator 12 , the security shim flags an error. Otherwise, the security shim 202 replaces the sequence number in the table 279 with the new sequence number.
  • the tag locally computes its own authentication checksum for these messages, and compares it to the authentication checksum received in the final message from the interrogator, in order to verify that they are identical. If this authentication fails, then the tag discards the messages.
  • the security shim 202 in the tag decrypts and reassembles the original table query message.
  • the security shim 202 saves the received CQRB bit for later use, and sets the communication type bit of the packet options field in the reconstructed headers to a binary “0”.
  • the security shim 202 then passes the reconstructed message on to the application program 111 of the tag.
  • the interrogator will transmit to all the tags a broadcast message containing a collection query command.
  • the application program 111 will generate an ISO 18000-7 compliant reply message.
  • the ISO headers of this message contain a tag status field, which in turn includes a “service bit” that represents tag's reply to the query.
  • This ISO message is intercepted by the security shim 202 in the tag, and the security shim performs an exclusive or (XOR) between the service bit and the CQRB bit, and substitutes the result for the service bit. Then without further change or tunneling, the security shim 202 transmits the modified ISO message to the interrogator 12 .
  • this ISO message is not encrypted or tunneled, the true value of the service bit cannot be determined.
  • the security shim 201 in the interrogator 12 When the security shim 201 in the interrogator 12 receives this ISO message, it takes the modified service bit from the tag status field in the ISO headers, and carries out an exclusive or (XOR) between this modified service bit and the previously-saved CQRB bit, in order to thereby recover the original value of the service bit. The security shim substitutes this recovered original service bit for the modified service bit in the ISO headers of the message, and then passes the message on to the application program 101 in the interrogator.
  • XOR exclusive or
  • the ISO 18000-7 standard has provisions for the interrogator 12 to transmit to multiple tags a broadcast request for a universal data block (UDB), expecting that each tag will then prepare and return a UDB.
  • the ISO 18000-7 standard has provisions for the interrogator 12 to transmit to one selected tag a P2P request for a UDB, and then only the selected tag will prepare and return a UDB.
  • the application program 101 in the interrogator 12 generates the broadcast ISO message for UDB collection.
  • the security shim 201 does not apply any encryption or other form of security to that message. Instead, the security shim 201 transmits the message at 28 without any change.
  • the tag's security shim 202 encrypts certain information in the UDB data that is being returned, as briefly mentioned earlier. This is explained in more detail below, with reference to FIG. 12 .
  • FIG. 12 is a diagram showing an ISO message 501 that contains one or more protected blocks 506 of UDB data, and also one or more authentication blocks 508 .
  • the UDB blocks 506 and the authentication blocks 508 are provided in pairs. That is, each UDB block 506 is associated with a respective different authentication block 508 .
  • the security shim 202 in the tag maintains a UDB recipient list 226 , and in the disclosed embodiment this list contains at least two UDB access control objects 227 and 231 .
  • the UDB message 501 contains a respective UDB block 506 for each access control object in the list 226 , and also contains a corresponding authentication block 508 for each access control object.
  • UDB blocks 506 is shown in more detail in the upper portion of FIG. 12 . It includes a section 516 of UDB data, and this section 516 contains one or more data elements that are each configured in a TLV format.
  • the application program 111 responds to a UDB request by collecting all of the data elements in the tag that could possibly be returned in reply to a UDB request.
  • each UDB access control object in the list 226 includes UDB access information, such as that shown at 229 or 233 in FIG. 6 .
  • the UDB access information defines which of the various UDB data elements the associated recipient is entitled to receive. In this example, as discussed above in association with FIG.
  • the UDB access information 229 for one recipient is different from the UBD access information 233 for another recipient.
  • the section 516 in one UDB block 506 will contain one set of data elements specified by one recipient's UDB access information 229
  • a different UDB block 506 will contain a different set of data elements identified by the other recipient's UDB access information 233 .
  • the UDB protection status information 241 will be used to determine whether or not each data element in each UDB block 506 will be protected by encryption.
  • each UDB block 506 includes a field 521 that contains a UDB sequence number in TLV format, and a further field 522 that contains tag identification information in TLV format.
  • the tag identification information at 522 includes both the tag manufacturer identification 122 ( FIG. 5 ) and also the tag serial number 124 .
  • the fields 516 , 521 and 522 are encrypted by the security shim 202 , using a randomly generated encryption key that is different for each UDB block 506 .
  • the random encryption key is then encrypted using the respective public key 228 or 232 ( FIG. 5 ) of the intended recipient of the particular UDB block 506 , and this encrypted key is placed in a field 524 of the block 506 , in TLV format.
  • the recipient of the block will have a private key corresponding to the public key 228 or 232 , and will thus be able to decrypt the field 524 in order to retrieve the random key. The recipient can then use this random key to decrypt and authenticate the fields 516 and 521 - 522 .
  • Each UDB block 506 also includes several other fields 526 - 530 .
  • the fields 526 and 527 are type and length information for the TLV format of the entire UDB block 506 .
  • the field 528 is a recipient identification in TLV format. In the disclosed embodiment, the recipient identification is the “distinguished name” from the particular recipient's X.509 certificate 225 or 230 ( FIG. 5 ).
  • the field 529 contains cryptographic information that will be needed by the recipient in order to decrypt the encrypted portions of the UDB 506 .
  • the field 530 contains authentication information in the form of a cryptographic checksum of all of the other fields (A 1 ) in that particular UDB block 506 , computed according to the authentication technique specified by the protection suite identified in the cryptographic information 529 , and using the random key that appears in encrypted form in field 524 .
  • each authentication block 508 includes six fields 541 - 546 .
  • the field 546 contains an authentication checksum that is based on all information (A 2 ) in the message 501 other than the authentication blocks 508 , as well as everything (A 3 ) in this particular authentication block 508 , other than the field 546 itself.
  • the fields 541 and 542 contain type and length information for the TLV format of the entire authentication block 508 .
  • the field 543 contains a recipient identification which is the same as that in the field 528 of the corresponding UDB block 506 .
  • the field 544 contains a cryptographic information TLV of the type shown in FIG.
  • the authentication checksum is generated with a random key. This random key is then encrypted using the public key 228 or 232 from the digital certificate of the intended recipient, and placed in a field 545 of the authenticaion block 508 .
  • the ISO message 501 of FIG. 12 containing UDB information is not itself encrypted and/or tunneled, because each of the UDB blocks 506 in this message 501 have portions that have already been separately encrypted. If the UDB blocks 506 and authentication blocks 508 have a collective size that is too large to be sent in a single ISO 18000-7 message, then this UDB “payload” is broken up into two or more segments in a manner specified by the ISO 18000-7 protocol, and the segments are sent in separate messages. Since persons skilled in the art are familiar with how, under the ISO 18000-7 standard, a UDB payload is to be segmented and how the segments are to be separately transmitted, that process is not shown and described in detail here. It is assumed for the sake of this discussion that the UDB payload is not sufficiently large to require segmentation. Consequently, the message shown at 501 will be wirelessly transmitted at 28 in the format shown at 501 .
  • the security shim 201 in the interrogator 12 will receive the message 501 , and then pass it on without change to the application program 101 , which will then forward it on to each of the intended recipients.
  • the users 22 and 23 in FIG. 5 respectively correspond to the UDB access control objects 227 and 231 in the tag 16 .
  • the application program 101 would forward the entire message 501 through the network 18 to each of the users 22 and 23 .
  • User 22 will have a private key that corresponds to the public key 228 in the certificate 225 , and will thus have cryptographic access to one UDB block 506 and the associated authentication block 508 .
  • the user 23 will have a different private key that corresponds to the public key 232 in the certificate 230 , and will thus have cryptographic access to a different UDB block 506 and the associated authentication block 508 .
  • the user 22 will be able to verify the two authentication checksums 530 and 546 in its pair of blocks 506 and 508 , and the user 23 will be able to separately verify the authentication checksums in the fields 530 and 546 of its pair of blocks 506 and 508 .
  • the tag owner when the tag 16 is first being commissioned, the tag owner will install the security officer access control object 210 that contains the root certificate 212 . At this point, the list 211 will not contain any other certificates, and the list 226 will be empty. Further, the cryptographic keysets in table 270 will not yet be defined.
  • the next step in the commissioning procedure is for a security officer (for example the user 21 ) to authenticate himself to the tag, for the purpose of defining keysets 271 - 274 that will allow the security shims 201 and 202 to exchange protected information in the manner described above.
  • the first task that the security officer must complete is to establish the security officer keyset 271 , in a manner explained in more detail below.
  • the security shim 201 transmits information to the tag 16 , using table write fragment commands that store information fragments in the P2P Request Table 251 , and using table read fragment commands to read information fragments from the P2P Response Table 252 , in a manner generally similar to that already described above.
  • the protection suite used for these particular exchanges is the NULL-NULL protection suite.
  • the security shims 201 and 202 exchange P2P ISO messages without using any encryption or authentication. This is because the exchange of information between the security officer and the tag in this particular situation is configured to be self-protecting.
  • FIG. 13 is a flowchart showing how a security officer can, through the interrogator 12 , authenticate to the root certificate 212 in the tag 16 , determine a protection suite, and establish the security officer keyset 271 .
  • This procedure begins at 571 .
  • the security officer has the security shim 201 generate a transient random public key and a transient random private key, which are respectively shown at 316 and 317 in FIG. 5 .
  • the security officer also has the interrogator's security shim 201 generate a random number RI.
  • the security officer then has the security shim 201 transmit selected information to the tag at 573 , using the tunneling technique discussed above in association with FIGS.
  • the information transmitted at 573 includes the security officer's digital certificate 301 (including its embedded public key 302 ), the list 311 of protection suites supported by the security shim 201 in the interrogator, the transient public key 316 , and the random number RI.
  • the security shim 202 in the tag compares the protection suite list 311 from the interrogator 12 to its own protection suite list 258 , in order to determine whether or not there is at least one protection suite common to both lists (other than the NULL-NULL protection suite). If there is no common protection suite, then the security shim 202 terminates its participation in the transaction, as indicated at 577 . Otherwise, the security shim 202 proceeds to block 578 , where it checks to see if the digital certificate 301 from the security officer is valid. For example, the digital certificate 301 specifies a range of dates within which it is valid, and the security shim 202 can verify that the current date maintained in the tag using clock 52 ( FIG.
  • the security shim 202 can also check the integrity of the certificate by verifying the issuer's signature, using the public key 302 from the security officer's digital certificate 301 . If the security shim 202 determines that there is a problem with the digital certificate 301 of the security officer, the security shim terminates the transaction at 577 .
  • the security shim 202 selects one protection suite that is common to both of the lists 311 and 258 (other than the NULL-NULL protection suite).
  • the security shim 202 also generates a random number RT.
  • the security shim 202 uses the transient public key 316 received from the interrogator at 573 to encrypt both the random number RT and an identification of the selected protection suite. Then, at 582 , this information is transmitted back to the security shim 201 in the interrogator 12 .
  • the transfer of this information is effected by putting the information in the P2P Response Table 252 , and then notifying the security shim 201 in the interrogator, so that the security shim 201 can retrieve this information from the table 252 in the manner discussed earlier.
  • the protection suite selected by the tag at block 581 is not yet in effect, and so all of the exchanges shown in FIG. 13 are carried out using the NULL-NULL protection suite.
  • the security shim 201 in the interrogator decrypts the information that it received at 582 from the security shim 202 in the tag.
  • the security shim 201 then computes an authentication value HI, according to the authentication technique identified in the protection suite selected by the security shim 202 in the tag, and using the random key RT received from the security shim 202 .
  • the security shim 201 generates a further random number SALT.
  • the security shim 201 concatenates the authentication value HI and the random number SALT, and signs the concatenated result with the private key 303 associated with the digital certificate 301 . This signed information is then transmitted at 584 to the security shim 202 in the tag.
  • the security shim 202 Upon receiving this information, the security shim 202 uses the public key 302 that it received in the security officer's certificate 301 , and verifies the signature in the information received at 584 . If the signature is not valid, then the security shim 202 ends the transaction at 577 .
  • the security shim 202 in the tag proceeds to block 587 , where it locally computes its own authentication checksum HT, and then compares this to the authentication checksum HI from the interrogator, in order to verify they are identical. If they are different, then the security shim 202 terminates the transaction at 577 . Otherwise, the security shim 202 proceeds to block 588 , where it generates the security officer (SO) keyset 271 .
  • the various messages received from the interrogator each include the interrogator identification code 103 ( FIG. 5 ), and of course the security shim 202 has also received from the interrogator's security shim 201 the random numbers RI and SALT.
  • the tag's security shim 202 concatenates (1) the random number SALT, (2) the random number RT, (3) the random number RI, (4) the tag serial number 124 , (5) the tag manufacturer identification 122 , and (6) the interrogator identification 103 .
  • the security shim 202 uses this concatenated information as an input to well-known algorithm referred to in the art as PBKDF2 (Password-Based Key Derivation Function), in order to derive material that is used as the security officer keyset 271 .
  • This keyset includes both an encryption key, and an authentication key.
  • the tag's security shim 202 saves this keyset at 271 .
  • the security shim 202 sends to the interrogator's security shim 201 a message that instructs the security shim 201 to change protection suites.
  • the security shim 202 then switches from use of the NULL-NULL protection suite to use of the protection suite selected at block 581 .
  • the interrogator's security shim 201 When the interrogator's security shim 201 receives the message sent at 591 , the it already has in hand all of the same information used by the tag's security shim 202 to generate the security officer keyset. Accordingly, at block 592 , the interrogator's security shim 201 separately derives and saves the security officer keyset 271 in the same manner that this keyset was derived by the tag's security shim 202 , in particular by concatenating the same information and then using the same PBKDF2 function. The security shim 201 in the interrogator then switches from use of the NULL-NULL protection suite to use of the protection suite selected by the tag at block 581 .
  • any further communications between the security officer and the tag will still be effected with tunneled messages routed through the P2P Request and Response Tables 251 and 252 , but using the security officer keyset 271 , and the protection suite selected at 581 .
  • the security officer can use the selected protection suite and the security officer keyset 271 to send the tag's security shim 202 a read-only keyset, which the security shim 202 stores at 272 for later use.
  • the security officer will normally provide this same read-only keyset to many different tags, so that broadcast messages sent to multiple tags can contain information encrypted with this keyset, and the various tags will each be able to decrypt the encrypted information.
  • the security officer can also use the security officer keyset 271 and the selected protection suite to instruct the tag's security shim 202 to generate a read/write keyset.
  • the security shim 202 will then generate random numbers for use as the read/write keyset, store the read/write keyset at 273 , and send the read/write keyset 273 back to the interrogator's security shim 201 .
  • the security officer can use the security officer keyset 271 and the selected protection suite to instruct the tag's security shim 202 to generate a tag response keyset.
  • the security shim 202 then generates random numbers for use as the tag response keyset, stores the tag response keyset at 274 , and sends the tag response keyset to the interrogator's security shim 201 .
  • the security officer can also instruct the tag's security shim 202 to invalidate all of the keysets that are currently stored in the table 270 , including the security officer keyset 271 .
  • the security officer sends a message instructing the tag's security shim 202 to invalidate all of the local keysets stored in table 270 .
  • the security shim 202 then sends back a message containing a random number.
  • the interrogator's security shim 201 increments the random number by 1 modulo 2 96 , and sends the result to the tag's security shim 202 .
  • the security shim 202 checks the incremented value and, if it is correct, the security shim 202 invalidates all of the keysets stored in the table 270 .
  • the security officer can optionally install additional access control objects in the tag.
  • the security officer can optionally install one or more additional security officer access control objects in the list 211 , such as the certificate shown in broken lines at 220 .
  • the security officer can optionally install one or more UDB access control objects in the list 226 , such as those shown in broken lines at 227 and 231 .
  • the tag access rights for that additional object cannot be greater than the tag access rights of the existing access control object that was used to create the security officer keyset being used by the security officer.
  • the security officer can view access control objects already installed on the tag, by sending a message that requests a list of the installed objects.
  • the tag will return a list containing the “subject name” field from the digital certificates in each of the access control objects currently installed in each of the lists 211 and 226 on the tag.
  • the security officer can use the security officer keyset 271 and the selected protection suite to optionally remove any of the access control objects that are already installed in either of the lists 211 and 226 , except for the access control object 210 containing the root certificate 212 .
  • the procedure for removing an access control object is similar to that for invalidating the keysets in table 270 .
  • the security officer sends a request that a particular access control object be deleted, and the security shim 202 in the tag returns a random number.
  • the security officer increments the random number by 1 modulo 2 96 , and returns the result.
  • the tag's security shim 202 checks the incremented result and, if it is correct, the security shim deletes the specified access control object.
  • the tag 16 maintains a not-illustrated log of all attempts to authenticate to or access the tag, including not only successful attempts, but also unsuccessful attempts.
  • FIG. 14 is a diagram showing three different sites 701 , 702 and 703 that are geographically spaced from each other.
  • the site 701 is a manufacturer's facility
  • the site 702 is a shipping hub
  • the site 703 is a customer's facility.
  • Products manufactured at the site 701 are loaded into a container 704 , and the previously-described tag 16 is physically attached to the container 704 .
  • the container 704 with the tag 16 will be shipped by truck from the manufacturer's site 701 to the shipping hub 702 , where the container 704 will be switched from the original truck to a further truck.
  • the container 704 with the tag 16 will then be transported by the further truck from the site 702 to the customer's site 703 , where the products will be removed from the container.
  • the site 701 has an interrogator 706
  • the site 702 has an interrogator 707
  • the site 703 has an interrogator 708 .
  • the interrogators 706 - 708 are each identical to the interrogator 12 that was described earlier, but have been given different reference numerals in FIG. 14 so that they can be separately identified.
  • the interrogators 706 - 708 are operatively coupled by the network 18 , which has already been discussed above.
  • the site 701 has a person 711 who serves as a security officer (SO)
  • the site 702 has a person 712 who serves as a security officer
  • the site 703 has a person 713 who serves as a security officer.
  • the security officer 711 at the site 701 uses the interrogator 706 to validate to the tag 16 , in the manner discussed above in association with FIG. 13 . As explained above, this results in the selection of a protection suite ( FIG. 7 ), and the generation of the security officer keyset 271 . The security officer 711 then proceeds to interact with the tag in order to also establish the read-only keyset 272 , the read/write keyset 273 and the tag response keyset 274 . The security officer 711 then distributes the read-only keyset 272 and the tag response keyset 274 to other not-illustrated persons at the site 701 who have operator status (Table 2).
  • the security officer 711 distributes the read-only keyset 272 , the read/write keyset 273 and the tag response keyset 274 to other not-illustrated persons at the site 701 who have administrator status.
  • This distribution of keysets will normally occur electronically under a secure protocol, but in some situations the keysets may be distributed in some other manner.
  • the binary values in a keyset could be converted into a printable format (for example base 64 or base 32 ), and then printed out. The printed information could then be given to a user (such as the user 24 in FIG. 1 ) who would then manually enter the information into an interrogator (for example using the manual keypad 66 of the handheld interrogator 13 ).
  • the security officer 711 then installs two additional security officer access control objects in the list 211 .
  • One of these is the access control object 220 .
  • the tag receives a communication from the security officer 712 at site 702 , the tag can use the certificate 221 in the object 220 to authenticate the security officer 712 .
  • the third access control certificate in the list 211 is not shown in FIG. 5 , but if the tag receives a communication from the security officer 713 at site 703 , the tag can use the third access control object to authenticate the security officer 713 .
  • the security officer 712 at site 702 will be provided with a security officer certificate that corresponds to the certificate 221 in the access control object 220 , and that is similar in type to the security officer certificate 301 .
  • the security officer 713 at site 703 will be provided with a further security officer certificate that corresponds to the certificate in the third access control object in the list 211 , and that is similar in type to the security officer certificate 301 .
  • the security officer 711 may also optionally install one or more UDB access control objects in the list 226 , for respective UDB recipients.
  • UDB access control object 227 For the purpose of the exemplary situation being discussed here, it is assumed that the security officer 711 installs the UDB access control object 227 , and that the certificate 225 in this object indicates a UDB recipient 721 is to receive UDB information. Further, it is assumed that the security officer 711 installs the UDB access control object 231 , and that the certificate 230 in this object indicates that a UDB recipient 722 is to receive UDB information.
  • the UDB recipients 721 and 722 are each a person or entity that does not fall within any of the four security levels listed in Table 2 .
  • the keysets in table 270 can remain in effect so long as the tag 16 remains at the site 701 , unless local security policy specifies that they should be invalidated and replaced sooner. It is assumed for the sake of this discussion that the keysets in table 270 are permitted to remain in effect so long as the tag is at the site 701 . While the tag 16 is at the site 701 , persons with operator status or administrator status can interact with the tag 16 . For example, a person with administrator status may install on the tag 16 a manifest (inventory) of the products that have been loaded into the associated container 704 .
  • a manifest inventory
  • the security officer 711 uses the security officer keyset 271 to instruct the tag 16 to invalidate all four of the keysets 271 - 274 that are stored in table 270 .
  • the departure gate from the site 701 could be a choke point having an interrogator or reader that automatically invalidates the keysets in table 270 on every tag departing the site 701 .
  • the container 704 with tag 16 will then be transported by the truck to the shipping hub site 702 .
  • the security officer 712 at that site will use the interrogator 707 to authenticate to the certificate 221 in the tag 16 , using the technique described above in association with FIG. 13 .
  • This will result in the selection of a protection suite for use at the site 702 , and also the creation of a unique security officer keyset that will be stored in the tag at 271 , and used by the security officer 712 to communicate with the tag.
  • the security officer 712 will then establish additional keysets 272 - 274 for use within the site 702 , and will distribute these keysets to other persons at the site 702 who have operator or administrator status with respect to the tag 16 .
  • the tag 16 receives through the interrogator 707 an ISO message that instructs the tag 16 to prepare and transmit UDB information.
  • the tag 16 will then create and transmit a message of the type shown at 501 in FIG. 12 , including one UDB block 506 that is based on the access control object 227 and intended for the UDB recipient 721 , and a further UDB block 506 that is associated with the access control object 231 and intended for the UDB recipient 721 .
  • the message 501 will also include two authentication blocks 508 , each of which is associated with a respective one of the two UDB blocks 506 .
  • Interrogator 707 will forward the message 501 through the network 18 to each of the UDB recipients 721 and 722 .
  • the UDB recipient 721 has a private key that corresponds to the public key 228 in the UDB certificate 225 .
  • the recipient 721 uses that private key to decrypt the random keys received at 524 and 545 in the UDB block 506 and associated authentication block 508 that are intended for the UDB recipient 721 .
  • the recipient 721 can use the authentication information to authenticate the received message, and can access the UDB data 516 .
  • the UDB recipient 722 has a private key that corresponds to the public key 232 in the UDB certificate 230 .
  • the UDB recipient 722 uses that private key to decrypt the random keys received at 524 and 545 in the UDB block 506 and associated authentication block 508 that are intended for the recipient 722 .
  • the UDB recipient 722 can use the authentication information to authenticate the received message, and can access the UDB data 516 .
  • UDB recipient 721 can access the UDB data in the message 501 for which the recipient 721 is the intended recipient, but not UDB information intended for any other recipient, such as the UDB recipient 722 .
  • the UDB recipient 722 can access the UDB data in the message 501 for which the recipient 722 is the intended recipient, but not UDB information intended for any other recipient, such as the UDB recipient 722 .
  • the message 501 with encrypted UDB information is passing through the network 18 from site 702 to the UDB recipients 721 and 722 , the message 501 may pass through computers or systems of third parties, but those third parties will not be able to access or view any of the encrypted UDB information that is present within the message.
  • the security officer 712 will instruct the tag 16 to invalidate all of the keysets that are stored on the tag in table 270 .
  • the departure gate from the site 702 could be a choke point having an interrogator or reader that automatically invalidates the keysets in table 270 on every tag departing the site 702 .
  • the further truck carrying the container 704 and the tag 16 will arrive at the customer's site 703 .
  • the security officer 713 at that site will use the interrogator 708 to authenticate to the third (not-illustrated) certificate in the list 211 , in order to select a protection suite and establish a security officer keyset that the tag stores at 271 .
  • the security officer 713 will also establish all the additional keysets 272 - 274 for use at the site 703 , and distribute these additional keysets to appropriate persons at site 703 .
  • the tag 16 After the container 704 has been unloaded, the tag 16 will be removed from the container. A person with administrator status may remove information from the tag that is viewed as sensitive or confidential, such as the manifest or inventory for the container 704 .
  • the security officer 713 will then instruct the tag to invalidate all the keysets stored in table 270 .
  • the security officer 713 may also remove one or more of the additional access control objects that are installed in the list 211 or in the list 226 , except that the security officer 713 cannot remove the access control object 210 containing the root certificate 212 .
  • the tag owner can remove and/or replace the access control object containing the root certificate 211 .
  • the RFID system 10 of FIGS. 1 and 5 - 14 provides a high level of security for information exchanged between an interrogator and a tag, as well as information maintained in the tag, while remaining fully compatible with the existing ISO 18000-7 standard.
  • the security provisions are structured so that they can be implemented with just a firmware upgrade in existing interrogators and tags, without any hardware change. Consequently, many existing interrogators and tags can be relatively easily and cheaply upgraded, while avoiding the expense of completely replacing them, or the expense and logistical problems involved in implementing hardware alterations. Avoiding the need for extra hardware in tags also avoids the increased power consumption that would be associated with added hardware, and thus helps to avoid a reduction in the period of time that a tag can operate before its battery needs to be changed or recharged.

Abstract

A method and apparatus involve storing in a tag a selected digital certificate that permits secure access to said tag from externally thereof.

Description

  • This application claims the priority under 35 U.S.C. §119 of provisional application No. 60/951,334 filed Jul. 23, 2007, the disclosure of which is hereby incorporated herein by reference.
  • FIELD OF THE INVENTION
  • This invention relates in general to radio frequency identification systems and, more particularly, to techniques for protecting information in radio frequency identification systems.
  • BACKGROUND
  • Radio frequency identification (RFID) systems are used in a variety of different applications. As one example, RFID systems are commonly used to track and monitor shipping containers or other objects. RFID tags are attached to the containers or other objects, and can exchange wireless communications with stationary interrogators. In order to provide end users with compatibility among components obtained from different manufacturers, an international industry standard for RFID communications has been developed and promulgated by the International Organization for standardization (ISO) in Geneva, Switzerland. This standard is commonly known as the art as the ISO 18000-7 standard.
  • Although the ISO 18000-7 standard been very beneficial, it offers little in the way of security for information. For example, the standard does not allow wireless messages to be encrypted, nor does it have any built-in extension mechanism that would permit the definition of proprietary messages within the protocol, such as proprietary messages with security provisions. Consequently, information transmitted in wireless messages under the ISO 18000-7 standard is fully visible to any entity that elects to receive the wireless messages. A third party may be able to emulate or interfere with ISO 18000-7 messages in various different ways. Consequently, while the ISO 18000-7 standard has been adequate and beneficial for its intended purposes, it has not been entirely satisfactory in all respects.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A better understanding of the present invention will be realized from the detailed description that follows, taken in conjunction with the accompanying drawings, in which:
  • FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system, and that embodies aspects of the present invention.
  • FIG. 2 is a block diagram of a conventional RFID system in which an interrogator and a tag exchange wireless communications conforming to an industry standard known as ISO 18000-7.
  • FIG. 3 is a diagram showing a data format used within the ISO 18000-7 standard.
  • FIG. 4 is a diagram showing a highly-generalized message format used under the ISO 18000-7 standard.
  • FIG. 5 is a block diagram showing a portion of the system of FIG. 1, and showing selected aspects of computer programs executed by some of the depicted components.
  • FIG. 6 is a diagram showing in more detail certain information maintained and used in the system of FIG. 5.
  • FIG. 7 is a table showing examples of five protection suites used within the system of FIG. 5, each protection suite being a combination of an encryption technique and an authentication technique.
  • FIG. 8 is a diagram showing how an ISO 18000-7 message is compressed, encrypted and fragmented for purposes of transmission within the system of FIG. 5.
  • FIG. 9 shows a data storage format that is used for certain cryptographic information within the system of FIG. 5.
  • FIG. 10 is a diagram showing four ISO 18000-7 envelope messages that can be used in the system of FIG. 5 to transmit fragments of another ISO 18000-7 message.
  • FIG. 11 is a diagram similar to FIG. 10, but showing four ISO 18000-7 envelope messages of a different type.
  • FIG. 12 is a diagram showing an ISO 18000-7 message 501 that is used within the system of FIG. 5 to send separately protected segments of universal data block (UDB) information to respective different recipients.
  • FIG. 13 is a flowchart showing part of a procedure used to initialize an RFID tag in the system of FIG. 5.
  • FIG. 14 is a diagram showing three different sites that are geographically spaced from each other, and that each utilize an RFID system of the type shown in FIG. 5.
  • DETAILED DESCRIPTION
  • FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system 10, and that embodies aspects of the present invention. The system 10 includes two interrogators 12 and 13, an RFID tag 16, and a network 18. FIG. 1 also shows several users 21-24 that can each use or interact with the system 10. A user may be an individual, an entity, a computer, or some other automated device. FIG. 1 is not intended to depict the entire RFID system. For example, the system actually includes a plurality of the tags 16, and more interrogators than just the two that are shown at 12 and 13. FIG. 1 shows only selected portions of the RFID system that facilitate an understanding of the present invention.
  • The tag 16 is a mobile, battery-operated device, and can communicate in a wireless manner with each of the interrogators 12 and 13, in particular by exchanging radio frequency (RF) wireless signals 28. In the disclosed embodiment, all of the wireless signals 28 conform to an existing international industry standard known as ISO 18000-7. This international standard was promulgated by the International Organization for Standardization (ISO), headquartered in Geneva, Switzerland. Persons skilled in the art are familiar with the ISO 18000-7 standard. For brevity and clarity in the discussion that follows, the term “ISO” is used as a shorthand way to refer to the ISO 18000-7 standard, and should be understood to be a reference to the ISO 18000-7 standard, rather than a reference to the ISO organization itself.
  • The circuitry within the tag 16 includes a processor 41 that is coupled to a memory 42. The memory 42 in FIG. 1 is a diagrammatic representation of two or more different types of memory, including but not limited to read-only memory (ROM), random access memory (RAM), and flash memory. The memory 42 contains a program 43 that is executed by the processor 41, and data 44 that is utilized by the program 43. The circuitry of the tag also includes a serial port 51, through which a not-illustrated external computer or other device can communicate serially with the processor 41. The tag 16 has an internal clock circuit 52 with a not-illustrated oscillator, allowing the tag 16 to maintain a record of the current date and time.
  • The circuitry of the tag further includes a radio frequency (RF) receiver 46 that is coupled to the processor 41 and to an antenna 47. The processor 41 can receive wireless signals 28 through the antenna 47 and receiver 46. The tag also includes an RF transmitter 48 that is coupled to the processor 41 and to an antenna 49. The processor 41 can transmit wireless signals 28 through the transmitter 48 and the antenna 49.
  • The interrogator 13 is a portable, battery-operated, handheld device that can be manually operated by a user 24 who is an individual. The circuitry in the interrogator 13 includes a processor 56 that is coupled to a memory 57. The memory 57 is a diagrammatic representation of various different types of memory, including but not limited to ROM, RAM and flash memory. The memory 57 contains a program 58 that is executed by the processor 56, as well as data 59 that is used by the program 58. The interrogator 13 includes an RF transmitter 61 that is coupled to the processor 56 and to an antenna 62. The processor 56 can transmit wireless signals 28 through the transmitter 61 and the antenna 62. The interrogator also includes an RF receiver 63 that is coupled to the processor 56 and to an antenna 64. The processor 41 can receive wireless signals 28 through the antenna 64 and the receiver 63. The handheld interrogator 13 further includes a keypad 66 that is coupled to the processor 56. The user 24 can manually operate the keypad 66 in order to enter information into the interrogator 13.
  • The interrogator 12 includes a site manager 71 and a reader 72 that are operatively coupled at 73. In the disclosed embodiment, the coupling 73 between the site manager 71 and reader 72 is hardwired rather than wireless, and in particular is a network that may conform to a well-known network protocol known as the Ethernet protocol. Alternatively, however, the site manager 71 and reader 72 could be coupled in any other convenient manner, and could even communicate using wireless signals. Within a given site, such as a shipping hub, there may be a plurality of the readers 72 that are provided at spaced locations and that are all coupled to the site manager 71 through the network 73. However, for simplicity and clarity, FIG. 1 shows only a single reader 72.
  • As explained earlier, the wireless signals 28 conform to the ISO 18000-7 industry standard, and the discussion below will focus to some extent on this industry standard. In the real world, the site manager 71 and reader 72 are separate and independent devices that are physically and functionally distinct. However, the ISO 18000-7 standard basically recognizes two general categories of devices, one of which is tags, and the other of which is interrogators. Therefore, for simplicity and clarity in the discussion that follows, the site manager 71 and the reader 72 are collectively referred to herein as an interrogator 12. In addition, and for simplicity and clarity, the reader 72 is considered herein to be essentially a pass-through device, which facilitates the exchange of ISO messages 28 between the site manager 71 and the tag 16, but without making substantive alterations to any of the messages traveling in either direction.
  • The reader 72 includes a circuit 76. An RF transmitter 81 is coupled to the circuit 76, and to an antenna 82. The circuit 76 can transmit wireless signals 28 through the transmitter 81 and the antenna 82. An RF receiver 83 is coupled to the circuit 76 and to an antenna 84. The circuit 76 can receive wireless signals 28 through the antenna 84 and the receiver 83.
  • The site manager 71 includes a processor 86 that is coupled to a memory 87. The memory 87 is a diagrammatic representation of various different types of memory, including but not limited to ROM, RAM and flash memory. The memory 87 stores a program 88 that is executed by the processor 86, and also stores data 89 that is used by the program 88.
  • The user 21 can interact with the site manager 71. For example, the site manager 71 may include a not-illustrated terminal, and the user 21 may be an individual who interacts with the site manager through that terminal. The network 18 is operatively coupled to a network port of the site manager 71. The network 18 may include one or more of the Internet, an intranet, some other type of computer network, or a combination of two more such networks. The users 22 and 23 can communicate with the site manager 71 through the network 18. The users 22 and 23 may, for example, be individuals who are using personal computers or other terminals that are coupled to the network 18. Alternatively, the users 22 and 23 may be automated systems that are operatively coupled to the network 18. For example, the user 22 could be a site manager that is similar to the site manager 71, but that is located in a different site at a physically remote location.
  • As evident from the foregoing discussion, the tag 16 and the interrogators 12 and 13 each include both hardware and software (where the software may include firmware). In the embodiment of FIG. 1, the hardware in the interrogators 12 and 13 and in the tag 16 is entirely conventional. The new and unique characteristics discussed herein are embodied in the software, including the programs 43, 58 and 88 executed by the various processors in the tag 16 and interrogators 12 and 13. The new and unique characteristics in the program 88 of the interrogator 12 are essentially the same as those in the program 58 of the interrogator 13. Accordingly, for simplicity and to avoid redundancy, the discussion that follows will focus on the distinctive characteristics of the program 88 in the interrogator 12, as well as the distinctive characteristics of the program 43 in the tag 16. But before beginning a detailed discussion of the new and unique characteristics of the programs 88 and 43, it will be helpful to first briefly discuss the computer programs used in a conventional interrogator and tag.
  • In this regard, FIG. 2 is a block diagram of a system 10A that includes an interrogator 12A and a tag 16A that can exchange wireless communications 28 conforming to the ISO 18000-7 standard. In FIG. 2, components that are the same as or similar to components in FIG. 1 are identified with the same or similar reference numerals. For the purpose of this discussion, it is assumed that the hardware of the interrogator 12A of FIG. 2 is identical to the hardware of interrogator 12 of FIG. 1, and that the differences between these interrogators reside in the computer programs within them. Similarly, it is assumed that the hardware of the tag 16A of FIG. 2 is identical to the hardware of the tag 16 of FIG. 1, and that the differences between these tags reside in the computer programs within them. In FIG. 1, the subject matter depicted within the interrogator 12 and within the tag 16 represents primarily a high-level view of their hardware configurations. In contrast, in FIG. 2, the subject matter depicted within the interrogator 12A and within the tag 16A represents selected high-level aspects of the computer programs within the interrogator 12A and tag 16A.
  • In more detail, with reference to FIG. 2, the computer program in the interrogator 12A includes an application program 101. The data maintained by the application program 101 includes an interrogator identification code 103 that uniquely identifies the particular interrogator 12A. As mentioned earlier, a given site may include multiple interrogators and multiple tags, such that a given tag may be carrying on communications with more than one interrogator, and a given interrogator may be carrying on communications with more than one tag. Accordingly, when the interrogator 12A transmits a wireless ISO message at 28, the interrogator includes in the message its interrogator identification code 103, so that any tag receiving that message will know which particular interrogator sent the message.
  • The computer program executed in the tag 16A includes an application program 111. The application program 111 maintains a database of ISO tables 116, and examples of two ISO tables are shown diagrammatically at 117 and 118. The application program 111 includes a segment of user memory 121, and maintains a tag manufacturer identification code 122 that uniquely identifies the company that manufactured the tag 16A. The application program 111 also maintains a tag model number 123 corresponding to the tag 16A, and a tag serial number 124 that is unique to the particular tag 16A. The application program 111 further maintains a user-assigned identification code 125 that can be set and/or read by an external user, such as one of the users 21-23.
  • In addition, the application program 111 maintains a routing code 126. For example, if the tag 16A happen to be mounted on a container that is being shipped from a manufacturer to a remote shipping hub, and then from the shipping hub to a customer, the routing code 126 may be a code that identifies the particular shipping route. The application program 111 also contains a firmware revision number 127 identifying the particular version of the software/firmware computer program that is currently installed in the tag 16A. Further, the application program 111 maintains a tag password 128. If password protection in the tag is enabled, and if one of the users 21-23 wishes to communicate with the tag, then the user will first need to supply the tag with the correct password.
  • As discussed above, the interrogator 12A and the tag 16A exchange wireless communications 28 that conform to the ISO 18000-7 industry standard. FIG. 3 is a diagram showing one common data format 141 that is used within ISO 18000-7 messages. This data format 141 includes three fields, which are a type or “T” field 142, a length or “L” field 143, and a value or “V” field 144. Combining the first letters of the names of these fields yields the acronym “TLV”, and thus the data format 141 is commonly referred to as the “TLV” format. The type field 142 contains a code that uniquely identifies the type of data present in the value field 144. The length field 143 defines the length the value field 144, and in particular contains a number that represents the number of bytes present in the value field 144. The value field 144 contains one or more data elements (and each such data element may itself also have the TLV format). Persons skilled in the art are thoroughly familiar with the TLV data format shown in FIG. 3.
  • Referring again to FIG. 2, and as explained earlier, wireless messages 28 exchanged between the interrogator 12A and the tag 16A conform to the ISO 18000-7 standard. These ISO messages can have a variety of different formats. These formats are all defined in detail in the ISO 18000-7 specification, and they are therefore not all illustrated and described here in detail. Instead, FIG. 4 is a diagram showing a highly-generalized format 151 that is used for many types of ISO messages under the ISO 18000-7 standard. The message format 151 includes a section 153 of ISO headers, which is a collection of several different fields. The particular set of fields that are present at 151 will vary somewhat from message to message. For example, the ISO headers 153 always include a not-illustrated protocol identification field. The ISO headers 153 will typically also include the interrogator identification code 103 (FIG. 2) when the message is being transmitted by the interrogator 12A, but not if the message is transmitted by the tag 16A. Conversely, the ISO headers 153 will typically include the tag serial number 124 (FIG. 2) if the message is being transmitted by the tag 16A, but not if the message is being transmitted by the interrogator 12A. There are other fields that can also be present in the ISO headers 153, but since they are well known in the art, they are not all discussed in detail here.
  • The format 151 also includes a command code 154 to tell a receiving device what it is expected to do, a field 155 containing data and/or arguments for the command code 154, and an error checking field 156. The error checking field 156 typically contains a cyclic redundancy code (CRC) of a known type.
  • In regard to the command code shown at 154 in FIG. 4, Table 1 gives examples of some commands that the interrogator 12A of FIG. 2 can send to the tag 16A. It will be noted that some of these commands allow the interrogator 12A to read or write the user-assigned identification code 125 (FIG. 2), the routing code 126, or the user memory 121. Other commands allow the interrogator 12A to read the firmware revision number 127, or the tag model number 123. Still other commands allow the interrogator 12A to change the tag password 128, and to engage or disengage password protection. Still other commands allow the interrogator 12A to create a table within the database 116 of ISO tables, to write information into a table, or to read information from a table. Another command instructs the tag to enter a low-power “sleep” mode in which most (but not all) of the circuitry in the tag is turned off in order to conserve battery power. Still another command turns on or off a not-illustrated audible beeper that is located within the tag. Table 1 does not list all of the commands that exist under the ISO 18000-7 standard, but merely gives examples of some of those commands.
  • TABLE 1
    COMMAND COMMAND
    CODE NAME DESCRIPTION
    0x15 Sleep Put tag to sleep
    0x13 User ID Read user-assigned
    ID
    0x93 User ID Write user-assigned
    ID
    0x09 Routing Read routing code
    Code
    0x89 Routing Write routing code
    Code
    0x0C Firmware Retrieve firmware
    Revision revision number
    0x0E Model Retrieve tag model
    Number number
    0x60 Read/ Read user memory
    Memory
    0xE0 Write Write user memory
    Memory
    0x95 Set Set tag password
    Password
    0x17 Set Engage password
    Password protection
    protect
    0x97 Set Disengage password
    Password protection
    protect
    0x96 Unlock Unlock password
    protected tag
    0x70 Read Read Universal Data
    Universal Block
    Data
    Block
    0x26 Table Create database
    Create table
    0x26 Table Add Prepare to add new
    Records records to specified
    database table
    0x26 Table Prepare to modify
    Update specified table
    Records records
    0x26 Table Prepare to update
    Update specified fields of
    Fields a table record
    0x26 Table Delete existing
    Delete record from existing
    Record database table
    0x26 Table Get Prepare to retrieve
    Data specified table
    records
    0x26 Table Get Get total number of
    Properties records and size of
    each field
    0x26 Table Retrieve block of
    Read data from table, as
    Fragment initiated by Table
    Get Data command
    0x26 Table Write block of data
    Write into table, as
    Fragment initiated by Table
    Add Records, Table
    Update Records, or
    Table Update fields
    command
    0x26 Table Initiate table
    Query search based on
    specified criteria
    0xE1 Beep Turns tag's beeper
    On/Off On or Off
    0x8E Delete Delete all allocated
    Writeable writeable data on
    Data tag
  • In the discussion that follows, messages that are sent from the interrogator 12A to the tag 16A and that involve security fall generally within one of three different categories. First, even when a number of the tags are present, the interrogator 12A can select any one of the tags and send a message specifically to that one particular tag, and then expect a single response from that tag. This type of message is known as a Point-2-Point or “P2P” message.
  • In a second category of messages, the interrogator 12A can broadcast a single message to all of the security-enabled tags that are currently within the wireless transmission range of that particular interrogator. As one example, the interrogator can send one or more ISO “table query” broadcast messages to multiple tags, followed by an ISO collection query broadcast message. The interrogator then expects a single separate response from each individual tag. Messages in this category are referred to in this discussion as table query broadcast messages.
  • A third category of ISO messages is referred to as universal data block or “UDB” collection. In particular, the interrogator 12A can broadcast to multiple tags a common message that instructs each tag to formulate and send back a UDB data block. Each tag then prepares a UDB data block that has a predefined format, and that typically contains multiple items of data. For example, under the ISO 18000-7 standard, the UDB data block may include tag identification information (discussed in more detail later), and/or a routing code. Under proprietary extensions, various other data items could also be present. The various data elements in the UDB are typically each presented in the TLV format discussed above in association with FIG. 3. After each tag has prepared its UDB, the tag sends its UDB back to the interrogator 12A in a wireless message 28 that conforms to the ISO 18000-7 standard.
  • In FIG. 2, and as mentioned above, all of the wireless messages 28 sent between the interrogator 12A and the tag 16A conform to the ISO 18000-7 standard. But one resulting disadvantage is that these messages are not secure. For example, since these messages are sent as RF communications, a third party can easily receive these messages and/or transmit similar messages, and thus eavesdrop on or interfere with communications between the interrogator 12A and the tag 16A. For example, if the tag 16A transmits a wireless message that includes a UDB with a routing code therein, a third party can receive that RF message and thus learn routing information of the tag and any associated object such as a container.what is in the container. As another example, a third-party device can emulate a tag, and the interrogator 12A will not necessarily be able to tell that it is talking to an imposter rather than an actual valid tag.
  • As still another example, a third-party device can emulate an interrogator and communicate with the tag 16A. The tag will not know that it is communicating with an imposter rather than an actual valid interrogator. If the tag currently has password protection disabled, the third party device will be able to read or write data present within the tag, possibly in support of a fraudulent purpose. Moreover, if a valid interrogator happens to send the tag 16A a message that includes the current password for the tag, a third-party device can receive the message and learn the password. Using the password, the third-party device will have full read and write access to the tag. Moreover, using the current password, the third-party device could even replace the current password with a new password, thereby preventing a valid interrogator from subsequently communicating with the tag.
  • In order to avoid these and various other similar problems, it would be desirable to have some level of security for wireless ISO messages 28 being exchanged between the interrogator 12A and the tag 16A, while still complying with the ISO 18000-7 standard. However, the ISO 18000-7 standard does not have any provision for security in the wireless messages 28, through the use of encryption or otherwise. Moreover, the ISO 18000-7 standard does not have any built-in extension mechanism that would permit the definition of proprietary messages within the protocol, such as proprietary messages with security provisions. In order to address this, one aspect of the present invention involves the provision of a high level of security for information exchanged between an interrogator and a tag, while still remaining fully compatible with the existing ISO 18000-7 standard. Moreover, this is structured so that it involves only a firmware upgrade in each interrogator and each tag, without any hardware change. Consequently, existing interrogators and tags can be relatively easily and cheaply upgraded, without the need to incur the expense of completely replacing them, or the hassle and expense of hardware alterations.
  • In more detail, FIG. 5 is a block diagram showing a selected portion of the system 10 of FIG. 1, including the interrogator 12, the tag 16, the network 18 and the users 21-23. As noted above, the subject matter depicted in FIG. 1 within the interrogator 12 and within the tag 16 represents primarily a high-level view of their hardware configurations. In contrast, in FIG. 5 the subject matter depicted within the interrogator 12 and the tag 16 represents selected high-level aspects of the computer programs within the interrogator and tag. In this regard, FIG. 5 is similar in some respects to FIG. 2. It will be noted that the firmware of the interrogator 12 includes the conventional application program 101 that was discussed above in association with FIG. 2, and the firmware in tag 16 includes the conventional application program 111 that was discussed above in association with FIG. 2. The primary difference between FIG. 5 and FIG. 2 is that in FIG. 5 the firmware in the interrogator 12 includes an additional module in the form of a security shim 201, and the firmware in the tag 16 includes an additional module in the form of a security shim 202.
  • Conceptually, the security shim 201 is disposed between the application program 101 and the wireless messages 28 that are exchanged between the interrogator 12 and the tag 16. Similarly, the security shim 202 is conceptually disposed between the application program 111 and the wireless messages 28. If the application program 101 in the interrogator 12 wishes to securely transmit an ISO message to the application program 111 in the tag 16, the security shim 201 takes that ISO message, uses encryption and authentication techniques to add a level of security, and then sends a wireless message at 28 that contains the encrypted message with authentication information, while being fully compliant with ISO 18000-7. The security shim 202 in the tag then uses decryption to recover the original ISO message, and delivers that message to the application program 111. Similarly, if the application program 111 in the tag 16 has an ISO message to be securely transmitted to the application program 101 in the interrogator 12, the security shim 202 uses encryption to add a level of security, and then transmits a wireless message at 28 that contains the encrypted message but is fully ISO 18000-7 compliant. The security shim 201 in the interrogator then uses decryption to recover the ISO message, and delivers that message to the application program 101.
  • The security shims 201 and 202 are effectively transparent to the application programs 101 and 111. Moreover, even though the ISO messages exchanged at 28 in FIG. 5 differ in some respects from the messages that would be exchanged if the security shims 201 and 202 were not present, the messages exchanged at 28 are nevertheless all fully compliant with ISO 18000-7. Thus, the security shims 201 and 202 are transparent from the perspective of ISO compliance, because the messages 28 do not violate any of the requirements of the ISO 18000-7 standard.
  • Some of the information maintained by each of the security shims 201 and 202 will now be briefly identified. Then, an explanation will be provided as to how this information is used during system operation. Beginning with the security shim 202 in the tag 16, the security shim 202 maintains a security officer access control list 211. Whenever the tag is operational, the list 211 will include at least one security officer access control object 210 that in turn includes a digital certificate 212 known as the “root” certificate. The root certificate 212 contains a PKI public key 213. In the disclosed embodiment, the certificate 212 is a type of digital certificate conforming to an industry standard that is known as the X.509 standard, promulgated by the International Telecommunication Union (ITU) based in Geneva, Switzerland. Since this type of X.509 certificate is known in the art, it is not described here in detail.
  • In addition to the X.509 certificate 212, the access control object 210 includes tag access information 214 that defines the level of access that will be permitted to the tag 16 through use of the associated X.509 certificate. In a sense, the tag access information 214 can be viewed as a set of rules that govern access to the tag. In this regard, the security scheme implemented by security shims 201 and 202 recognizes four distinct levels of access to a tag, which are listed in Table 2.
  • TABLE 2
    ROLE DESCRIPTION
    Tag Owner Installs on tag the access control
    object containing the root certificate,
    and distributes corresponding
    certificates to security officer(s).
    Security Officer Can provision cryptographic keysets on
    tag, and distribute them to authorized
    persons and entities. Can install and
    remove additional security officer
    access control objects on tag. Can
    install and remove UDB access control
    objects.
    Administrator Receives keysets that allow read-only
    and also read/write access to tag.
    Operator Receives keysets that allow just
    read-only access to tag.
  • In Table 2, the lowest level of access is that of an “operator”, who has only read-only access to information on the tag. The next higher level of access is that of an “administrator”, who has read-only access, and also read/write access. The next higher level is that of a “security officer”, who can take security-related actions in the tag that will be described later, such as creating cryptographic keysets, and installing and removing digital certificates (other than the root certificate 212). The highest level of access is that of the tag owner, who has the power to install and remove the access control object 210 containing the root certificate 212. This may, for example, be effected through the serial port 51, as indicated diagrammatically by a broken line 216. IN fact, the overall degree of security is enhanced where operators, administrators and security officers carry out secure communications in one manner (for example through wireless communications), while the access control object 210 containing the root certificate 212 is installed in a different manner (for example through the serial port 51).
  • The tag access information at 214 indicates the maximum levels of access that can be obtained with the associated digital certificate 212. In this regard, the tag access information 214 indicates whether the associated digital certificate can be used to create keysets for read-only access, and whether the associated certificate can be used to create keysets for read/write access. In the case of the root certificate 212, it will normally be permissible to create keysets for read-only access and keysets for read/write access. This does not mean that everyone obtaining access with keysets created under this certificate will necessarily enjoy full access. For example, as discussed above in regard to Table 2, a person using operator keysets created under this certificate will be limited to read-only access, even if the tag access information indicates that read/write access is permissible. On the other hand, if the tag access information 214 indicates that read/write access is not permitted, then it will not be possible to create keysets under the associated certificate that would provide read/write access.
  • It is possible for a security officer using a security officer keyset created under one certificate (such as the root certificate 212) to optionally install one or more additional access control objects in the list 211, for example as shown at 220. The tag access information for one of these other access control objects might indicate that creation of read-only keysets under the associated certificate 221 is permitted, but that creation of read/write keysets under that further certificate is prohibited. If a security officer is using a security officer keyset created under an existing certificate in an existing access control object, and installs a further access control object, the tag access rights for that further object must not exceed the tag access rights in the existing object under which the security officer keyset was created.
  • The security shim 202 also maintains a further list 226 that is a universal data block (UDB) recipient list. The list 226 may be empty, or may optionally contain one or more UDB access control objects. For example, reference numeral 227 designates a UDB access control object containing a digital certificate 225 of a UDB recipient. In the disclosed embodiment, the UDB certificate 225 is an X.509 certificate, and contains a PKI public key 228. The UDB access control object 227 further includes UDB access information 229. The list 226 may optionally include a second UDB access control object 231 containing a digital certificate 230 with a public key 232, and UDB access information 233. It would be possible to combine the lists 211 and 226 into a single list that contains both types of access control objects. But for clarity in this discussion, two separate lists 221 and 226 are shown and described. In a sense, the UDB access information 229 and the UDB access information 233 can each be viewed as a set of rules that govern access to UDB information, as discussed below.
  • When the tag 16 receives an ISO message asking that the tag formulate and return a UDB, the UDB access control objects in the list 226 identify the persons or entities who will be the ultimate recipients of the tag's UDB information. In response to the ISO message presenting the UDB request, the application program 111 in the tag 16 collects all of the UDB information that is present within the tag. The security shim 202 in the tag intercepts this UDB information from the application program 111, uses the UDB access control objects in the list 226 to identify UDB recipients, and prepares a respective separate block of UDB data for each UDB recipient identified by the UDB access control objects 227 and 231 in the list 226. The security shim 202 does not necessarily pass all of the UDB information on to each of the recipients identified by the respective access control objects in the list 226. Instead, the UDB access information 229 or 233 in each access control object defines which items of UDB information will be received by the associated recipient.
  • For example, assume that the UDB information provided by the application program 111 is a set of N data elements Data 1 through Data N. Data 1 might be tag identification information, Data 2 might be a routing code, and Data N might be some other type of data. FIG. 6 is a diagram showing the UDB access information 229 associated with the UDB access control object 227, and also the UDB access information 233 associated with the UDB access control object 231. It will be noted that the UDB access information 229 associated with access control object 227 indicates the associated recipient is permitted to receive each of data elements Data 1, Data 2, and Data N (and possibly other UDB data elements that are between Data 2 and Data N). In contrast, the access information 233 associated with access control object 231 indicates the associated recipient is entitled to receive data element Data 1 (and possibly other data elements between Data 2 and Data N), but not data element Data 2 or data element Data N.
  • With reference to FIG. 5, the security shim 202 also maintains UDB protection status information 241. This information identifies the data elements in the tag's UDB information that will be protected by encryption and authentication, and the data elements that will not be protected. Referring again to FIG. 6, the UDB protection status information 241 is depicted twice, once in association with UDB access information 229, and again in association with UDB access information 233. In the exemplary embodiment, the UDB protection status information 241 indicates that data elements Data 2 and Data N will be protected, but that data element Data 1 will not be protected.
  • Since the UDB access information 229 indicates that the associated recipient is entitled to receive each of data elements Data 1, Data 2 and Data N, then when the security shim 202 receives UDB information from the application program 111 (including data elements Data 1 through Data N),the security shim 202 will formulate a UDB block for that recipient which includes each of Data 1, Data 2 and Data N (and possibly other data elements between Data 2 and Data N). Further, since UDB protection status 241 indicates that Data 2 and Data N need to be protected, the security shim 202 would encrypt data elements Data 2 and Data N. More specifically, the security shim 202 would generate a random key, use the random key to separately encrypt each of Data 2 and Data N, and then encrypt the random key with that recipient's public key 228.
  • Similarly, since the UDB access information 233 for the other UDB access control object 231 indicates that the associated recipient is entitled to receive data element Data 1 but not data elements Data 2 and Data N, then when the security shim 202 receives UDB information from the application program 111, the security shim 202 will formulate a UDB block for that recipient which includes Data 1 (and possibly other data elements between Data 2 and Data N), but not data elements Data 2 and Data N. The UDB protection status information 241 indicates that data elements Data 2 and Data N need to be protected, but this recipient is not receiving those data elements. This recipient is receiving data element Data 1, but the UDB protection status information 241 indicates that data element Data 1 does not need to be protected. Therefore, data element Data 1 would not be encrypted.
  • As discussed earlier, the application program 111 maintains a database 116 of ISO 18000-7 tables, and examples of two of these tables are shown at 117 and 118. The security shim 202 maintains a database 249 of three virtual ISO tables, which are a P2P Request Table 251, a P2P Response Table 252, and a Broadcast Request Table 253. These are referred to as virtual tables, because the application program 111 of the tag is not aware they exist. There are standard ISO commands that can be used to access ISO tables in the database 116, and the security shim 201 can use these same standard ISO commands to access the virtual ISO tables 251-253, as discussed in more detail later.
  • The security techniques used by the security shims 201 and 202 involve both (1) a cryptographic technique used to encrypt and decrypt information, and (2) an authentication technique used to authenticate information received in wireless ISO messages 28. The security shims 201 and 202 are each capable of working with any of several different cryptographic techniques, and with any of several different authentication techniques. A combination of one particular encryption technique and one particular authentication technique is referred to herein as a “protection suite”. The security shim 202 maintains a list 258 of the protection suites with which it is compatible. FIG. 7 is a table showing examples of five protection suites, which are the protection suites with which the security shim 202 is compatible. These five protection suites are merely exemplary, and it would be possible for the list 258 to contain a larger or smaller number of protection suites. It will be noted that the last protection suite in FIG. 7 is a NULL-NULL protection suite that does not use either encryption or authentication. This particular suite is utilized for a special purpose that is discussed in more detail later. The protection suite list 258 in the security shim 202 will always include the NULL-NULL protection suite, along with at least one other protection suite.
  • Referring again to FIG. 5, the security shim 202 maintains a keyset table 270 that can store four different cryptographic keysets 271-274. With reference to FIG. 5 and Table 2, the keyset 271 is a security officer (SO) keyset that can be used by a security officer when reading information from or writing information to the tag 16. Thus, the keyset 271 can be said to be bidirectional, in that it can be used for messages sent to the tag and also messages sent by the tag. The keyset 272 is a read-only keyset, and is used for messages that are sent to the tag by anyone other than a security officer, and that do not seek to change any information within the tag. The keyset 272 is unidirectional, in that it is used only for messages sent to the tag, and not for any messages sent by the tag. The keyset 273 is a read/write keyset, and can be used for messages that are sent to the tag by anyone other than a security officer, and that seek to change information within the tag. The keyset 273 is unidirectional, in that it is used only for messages sent to the tag, and not for any messages sent by the tag. The keyset 274 is a tag response keyset, and is used for messages sent by the tag to anyone other than a security officer. The keyset 273 is unidirectional, in that it is used only for messages sent by the tag, and not for any messages sent to the tag.
  • Still referring to FIG. 5 and Table 2, a person or entity with operator status would be given the read-only keyset 272 and also the tag response keyset 274. A person or entity with administrator status would be given the read-only keyset 272, the read/write keyset 273, and the tag response keyset 274. A security officer would use the security officer keyset 271 to carry out certain tasks specific to security officers.
  • Table 3 is an expanded version of Table 1, showing examples of some ISO commands for which the read-only keyset 272 is used, and examples of other ISO commands for which the read/write keyset 273 is used. The commands in Table 3 are merely exemplary, because Table 3 does not show all ISO commands. Where the tag replies to any command in Table 3, the tag would use the tag response keyset 274.
  • TABLE 3
    COMMAND COMMAND APPLICABLE
    CODE NAME DESCRIPTION KEYSET
    0x15 Sleep Put tag to sleep Read/Write
    0x13 User ID Read user-assigned Read-only
    ID
    0x93 User ID Write user-assigned Read/Write
    ID
    0x09 Routing Read routing code Read-only
    Code
    0x89 Routing Write routing code Read/Write
    Code
    0x0C Firmware Retrieve firmware Read-only
    Revision revision number
    0x0E Model Retrieve tag model Read-only
    Number number
    0x60 Read/ Read user memory Read-only
    Memory
    0xE0 Write Write user memory Read/Write
    Memory
    0x95 Set Set tag password Read/Write
    Password
    0x17 Set Engage password Read/Write
    Password protection
    protect
    0x97 Set Disengage password Read/Write
    Password protection
    protect
    0x96 Unlock Unlock password Read/Write
    protected tag
    0x70 Read Read Universal Data Read-only
    Universal Block
    Data
    Block
    0x26 Table Create database Read/Write
    Create table
    0x26 Table Add Prepare to add new Read/Write
    Records records to specified
    database table
    0x26 Table Prepare to modify Read/Write
    Update specified table
    Records records
    0x26 Table Prepare to update Read/Write
    Update specified fields of
    Fields a table record
    0x26 Table Delete existing Read/Write
    Delete record from existing
    Record database table
    0x26 Table Get Prepare to retrieve Read-only
    Data specified table
    records
    0x26 Table Get Get total number of Read-only
    Properties records and size of
    each field
    0x26 Table Retrieve block of Read-only
    Read data from table, as
    Fragment initiated by Table
    Get Data command
    0x26 Table Write block of data Read/Write
    Write into table, as
    Fragment initiated by Table
    Add Records, Table
    Update Records, or
    Table Update fields
    command
    0x26 Table Initiate table Read-only
    Query search based on
    specified criteria
    0xE1 Beep Turns tag's beeper Read/Write
    On/Off On or Off
    0x8E Delete Delete all allocated Read/Write
    Writeable writeable data on
    Data tag
  • As discussed earlier, FIG. 5 shows only a single interrogator 12 and a single tag 16, but it is possible for the tag 16 to carry on communications with more than one interrogator at the same time. The security shim 202 in the tag 16 maintains a table 279 that contains a record for each interrogator with which the tag is currently communicating. Each such interrogator is identified in the left column of the table by its interrogator identification code 103. For each such interrogator, the right column of the table 279 contains a sequence number. In this regard, any given interrogator may transmit a series of ISO wireless messages to the tag 16, and each of these messages will contain a sequence number, as discussed later. For each interrogator, the table 279 contains the sequence number from the message most recently received from that interrogator. Each time the tag receives a message from that interrogator, the security shim 202 checks to see whether the sequence number in the new message is greater than the sequence number currently stored in the table 297 for that interrogator. If the sequence number from the new message is equal to or less than the number in the table, then the security shim flags an error. Otherwise, the security shim accepts the new message, and replaces the sequence number in the table 279 with the sequence number from the new message.
  • Turning now to the security shim 201 in the interrogator 12, FIG. 5 shows that the security shim 201 includes security officer credentials 300, the credentials 300 including a security officer (SO) certificate 301 containing a public key 302, and a private key 303. In this example, the SO certificate 301 corresponds to the root certificate 212 in the tag 16. In this regard, the public key 302 in the credentials 300 was generated by concatenating the public key 213 of the root certificate 212 with a public key corresponding to the private key 303 in the credentials 300, and then signing the two concatenated keys with a not-illustrated private key corresponding to the public key 213. There are various ways in which the credential 300 can be introduced into the interrogator 12. As one example, the credentials 300 could be introduced into the interrogator 12 from a portable memory device 306 of a known type, such as a Universal Serial Bus (USB) flash memory device, or a device of the type commonly known as a “smartcard”.
  • As discussed above, a protection suite is a combination of one particular encryption technique and one particular authentication technique. The security shim 201 includes a list 311 of protection suites with which it is compatible. This protection suite list 311 is conceptually similar to the protection suite list 258 discussed earlier in association with the security shim 202 and FIG. 7. However, the set of protection suites identified in the list 311 may not necessarily be identical to the set of protection suites identified in the list 258. However, both lists will include the NULL-NULL protection suite (FIG. 7), as well as at least one other protection suite. In order for the security shims 201 and 201 to exchange secure information, the lists 258 and 311 will need to have at least one protection suite in common (other then the NULL-NULL protection suite).
  • The security shim 201 can generate and temporarily save a transient PKI public key 316 and a corresponding transient PKI private key 317, for a purpose discussed in more detail later. The security shim 201 also includes encrypted storage 326 that may be empty, but that will typically include one or more keyset tables, two examples of which are shown at 327 and 328. The keyset tables 327 and 328 are each similar to the keyset table 270 discussed above, which contains four keysets 271-274. For the purpose of this discussion, it is assumed that the keyset table 327 is for the tag 16 and is thus identical to the keyset table 270 in the tag 16, and that the keyset table 328 corresponds to a different tag and thus is not identical to the keyset table 270 in tag 16. However, there may be some commonality. For example, for reasons discussed later, the keyset tables 327 and 328 may each contain a read-only keyset that is identical to the read-only keyset 272 in the tag 16. In the disclosed embodiment, the encryption technique used for protecting the storage 326 is implemented with the Microsoft® Cryptographic API (CAPI) available on the Windows XP® and Windows CE® platforms (CE-CRYPTO). However, the encryption could alternatively be implemented using any other suitable encryption platform.
  • As mentioned above, the storage 326 is encrypted. In order to provide for restricted access to this encrypted storage 326, the security shim 201 maintains an access control section 336 that contains one or more access control blocks each corresponding to a respective different user. For example, the control section 336 contains an access control block 341 that has a user identification 342, a password 344, and an identification 343 of one or more keyset tables 327-328 that the specified user is authorized to use. Similarly, another access control block 346 has a user identification 347 that identifies a different user, a password 349 for that user, and an identification 348 of one or more keyset tables 327-328 that the user is authorized to use. When, for example, the user 342 provides the proper password 344 to the control section 336, each keyset table identified at 343 is obtained from encrypted storage 326, decrypted, and then made available for use by that user. Each user is permitted to freely change his or her password. Depending on the circumstances, and where appropriate, the security officer credentials 300 could also be maintained in protected storage, with access thereto controlled by the access control section 336.
  • As discussed earlier, the ISO 18000-7 standard does not have any provision for protecting ISO messages that are being transmitted. Moreover, this ISO standard does not have a built-in extension mechanism permitting the definition of new and proprietary messages that conform to the standard but that could also use encryption or some other security mechanism. Accordingly, the security shims 201 and 202 implement a unique technique that complies with the ISO 18000-7 standard but that provides strong security for ISO messages exchanged between the application program 101 in the interrogator and the application program 111 in the tag 16. According to this technique, the actual original ISO 18000-7 message is encrypted, then transmitted as a payload within at least one other ISO 18000-7 message that is not encrypted and that effectively serves as an envelope for the encrypted original message. This approach of embedding one ISO message within another is referred to herein as “tunneling” the encrypted message within the envelope message.
  • In more detail, and as discussed earlier, the ISO 18000-7 standard includes commands that permit the interrogator 12 of FIG. 5 to access ISO tables in the database 116, such as the exemplary tables shown at 117 and 118. The security shim 201 of the interrogator 12 uses the same ISO table commands for envelope messages, in order to access the virtual tables 251-253 in the security shim 201. Thus, if the application program 101 in the interrogator 12 has an ISO message that is to be sent to the application program 111 in the tag 16, the security shim 201 intercepts this ISO message, adds encryption and authentication, and then transmits it as the payload in at least one enveloping ISO message containing a table write fragment command directed to one of the virtual tables 251 or 253.
  • As a practical matter, the encrypted and authenticated command will usually be too large to be sent as the payload of a single ISO message. This is due in part to the fact that, in the United States, the Federal Communications Commission limits RFID infrastructure transmissions to 25 msec out of any 100 msec time window, which effectively limits each message to a length of about 100 bytes. Other countries and local authorities may also impose constraints. Accordingly, since the encrypted and authenticated command will usually be too large to embed within a single ISO message, it will typically be broken into several fragments, and then the fragments will be sent separately to the table 251 or 253 in respective different enveloping messages that are each an ISO table write fragment command. When all of the fragments have been written into the virtual table 251 or 253, the security shim 202 will retrieve and reassemble the fragments, authenticate and decrypt the result in order to recover the original ISO command, and then deliver this ISO command to the application program 111.
  • Conversely, if the application program 111 in the tag 16 has an ISO message to send to the application program 101 in the interrogator 12, the security shim 202 can intercept this ISO message, add encryption and authentication, fragment the message, and put the fragments into the virtual table 252. The security shim 202 then notifies the security shim 201, and the security shim 201 retrieves these fragments from the virtual table 252 using successive ISO table read fragment commands. That is, the fragments are each transported as the payload of a respective envelope ISO message sent in response to an ISO table read fragment command. When the security shim 201 has retrieved all of the fragments from the table 252, it reassembles the fragments and then authenticates and decrypts the result, in order to recover the original ISO message. The security shim 201 then delivers the original ISO message to the application program 101. With reference to an earlier discussion herein of different categories of messages, the virtual tables 251 and 252 are used for P2P messages and responses, and the virtual table 253 is used for broadcast table query messages.
  • FIG. 8 is a diagram showing in more detail how this can be accomplished for an ISO 18000-7 P2P message 401 that is generated by the application program 101. The command 401 has a standard ISO format, including ISO headers 402, a command code 403, a length value 404, and data 405. In order to reduce the amount of information that must be encrypted and tunneled, some of the ISO headers 402 from the message 401 are dropped, in order to obtain a compressed version 411 of the ISO headers 402. This is shown in more detail in Table 4.
  • TABLE 4
    ACTION HEADERS
    Header would be the same in both Packet Options
    the tunneled message and the Tag Manufacturer ID
    envelope message. Omit from header Tag Serial Number
    of tunneled message, and then Interrogator ID
    recreate at receiving end by
    copying from the equivalent header
    in the envelope message.
    Omit from header of tunneled Packet Length
    message, and then recreate at CRC
    receiving end by re-computing the
    value.
    To protect this information, Tag Status
    preserve this header in the
    tunneled message, and set the
    corresponding header of the
    envelope message to always indicate
    a positive response from tag.
  • In this regard, if all of the ISO headers 402 were retained in the tunneled message, some of them would necessarily always be identical to their counterparts in the ISO headers of the envelope message. Accordingly, these headers are omitted from the tunneled message. At the receiving end, they are added back to the tunneled message by simply copying the counterparts from the envelope message. As shown in Table 4, these include well-known ISO headers such as packet options, tag manufacturer identification, tag serial number, and interrogator identification code. As another example, some of the ISO headers 402 of the tunneled message would not necessarily be identical to their counterparts in the envelope message, but can be omitted from the tunneled message, and then recreated at the receiving end by recomputing them. As shown in Table 4, these include the well-known ISO headers of packet length and CRC error checking.
  • One other ISO header of interest is the tag status header. This header is maintained without change in the tunneled message. In theory, the counterpart header in the envelope message could be identical. However, this status information in the header of the envelope message would then be publicly accessible to anyone within the transmission range of the tag. In order to avoid making this status information available to anyone other than the intended recipient(s), and as indicated in Table 4, the ISO tag status header in each envelope message is unconditionally set to indicate a positive status response from the tag, regardless of whether the tag status header in the tunneled message happens to be positive or negative. Consequently, other parties who may look at the envelope message will always see it reflecting a positive tag status, and will not know whether the actual tag response was positive or negative.
  • Referring again to FIG. 8, reference numeral 412 identifies the compressed version of the original ISO message 401. As between any pair of transmitting and receiving devices, a selected common protection suite will be in effect. As discussed above, that protection suite will identify both an encryption technique and an authentication technique. In addition, between that same pair of devices, it will be possible to identify an appropriate cryptographic keyset which, depending on the circumstances, may be the security officer keyset 271, the read-only keyset 272, the read/write keyset 273, or the tag response keyset 274. The compressed ISO message 412 is encrypted using the appropriate keyset and using the encryption technique specified in the selected protection suite (unless the suite specifies NULL rather than an encryption technique). The resulting encrypted information 416 is expressed in TLV format.
  • Next, a cryptographic information TLV 417 is concatenated to the encrypted information TLV 416. The cryptographic information TLV is not itself encrypted, but indicates how the information 416 was encrypted, including an identification of the particular protection suite used and the particular keyset used. FIG. 9 is an example of how the cryptographic information TLV 417 would appear if the selected protection suite was the AES-128-CTR-HMAC-SHA1-96 suite of FIG. 7. The cryptographic information TLV 417 and the encrypted information TLV 416 represent the protected payload 421 that is to be transmitted. This payload will usually be too long to be sent in a single ISO envelope message. Therefore, the protected payload 421 is typically fragmented in a way that minimizes the number of fragments that must be separately sent. In the example shown in FIG. 8, this results in three fragments FRAG1, FRAG2, and FRAG3. Each fragment is then expressed in TLV form, in order to obtain three fragment TLVs F1, F2, and F3, which will each be sent in a respective separate ISO envelope message.
  • FIG. 10 is a diagram showing four ISO envelope messages 436-439, each of which contains a table write fragment command directed to the virtual table 251 in FIG. 5. The ISO messages 436-438 each include a respective one of the fragment TLVs F1, F2, and F3. The fourth ISO message 439 contains a TLV 441 with authentication information. The authentication information 441 includes a sequence number, and also a checksum value that will be explained later. With respect to the sequence number, and according to the ISO 18000-7 standard, the original ISO message 401 (FIG. 8) contains a sequence number. This sequence number from the original ISO message 401 is the sequence number in the authentication information 441 of the ISO message 439.
  • It is well known in the art how, under the ISO standard, several ISO table write fragment commands such as those shown at 436-439 in FIG. 10 can be used to write respective fragments of related information into a table such as the P2P Request Table 251 in FIG. 5. Therefore, this technique is not described in detail here. Instead, it is discussed only briefly, to an extent that facilitates an understanding of aspects of the present invention.
  • To initiate the process, the security shim 201 of the interrogator 12 transmits to the tag 16 a not-illustrated ISO table update record command, which serves as a request for permission to update the table 251. The security shim 202 of the tag 16 then sends back an ISO message containing a value that is commonly referred to as an operation initiation token. This and other similar tokens are random values, which adds to the security of a given message exchange. The interrogator 12 then sends the ISO message 436 in order to put the fragment TLV F1 in the table 251, and the tag responds by transmitting an ISO message with an operation continuation token. The interrogator then transmits the ISO message 437, and receives back an ISO message with a further continuation token. The interrogator then transmits the ISO message 438, and receives back another ISO message with a continuation token. The interrogator then transmits the ISO message 439. The checksum in the authentication TLV 441 of the message 439 is computed by concatenating all messages that have been exchanged between the interrogator and the tag, beginning with the initial table update record message, and including all messages sent by the tag with continuation tokens, as well as the final message 439, except for the authentication portion of the final message 439. This authentication checksum is computed according to the authentication technique indicated in the protection suite identified by the cryptographic information TLV 421 (FIG. 8), and using the appropriate keyset.
  • When all of the ISO 18000-7 messages 436-439 have been received by the tag and are present in the table 252, the security shim 202 in tag 16 takes the sequence number from the authentication information 441 in the final message 439, and compares that sequence number to the sequence number currently stored in the table 279 for the interrogator 12. If the sequence number from the message 439 is less than or equal to the sequence number currently stored in the table 279, the security shim 202 flags an error. Otherwise, the security shim 202 replaces the sequence number in table 279 with the new sequence number from the authentication information in message 439. Then, the security shim 202 locally computes its own authentication checksum, and compares it to the authentication checksum received in the authentication information 441 of the message 439, in order to confirm that the checksums are identical. If the tag detects an error at any time during the exchange of messages, then the tag sends the interrogator an ISO 18000-7 error message of a known type. Upon receiving this error message, the security shim 201 in the interrogator 12 discontinues the transmission, and notifies the application program 101 about the error.
  • On the other hand, if the security shim 202 in the tag has not identified any errors, and if the authentication checksum is verified successfully, then the security shim 202 (1) reassembles the fragments F1, F2, and F3, (2) decrypts this reassembled information, and (3) replaces or recreates the missing ISO headers, in order to thereby end up with the original message that is shown in 401 at FIG. 8. The security shim 202 then delivers this ISO message 401 to the application program 111 in the tag 16.
  • In response to the command in the ISO message 401, the tag will send a response back to the interrogator. This response is handled in a manner that is only slightly different from the manner described above for the message 401. In particular, the application program 111 in the tag 16 formulates an ISO message containing its response. Then, in a manner similar to that shown in FIG. 8, the security shim 202 compresses the ISO headers, encrypts the result, adds a cryptographic information TLV, and puts the resulting fragment TLVs in the P2P Response Table 252. The tag then sends the interrogator an ISO message containing a special token that indicates to the security shim 201 in the interrogator that a secure response is ready, and waiting to be retrieved. This prompts the interrogator to read the fragment TLVs from the table. For the most part, the manner in which this is carried out is known under the ISO 18000-7 standard, and the retrieval of the fragments is therefore described only briefly here.
  • In response to the token from the tag, the interrogator sends back an ISO message containing an ISO table get data command, and the tag responds with an operation initiation token that is a random value. The interrogator then sends an ISO table read fragment command to the tag, and the tag sends back an ISO message containing the first fragment and a further random token. The interrogator then requests the next fragment, and so forth. After the tag sends the last actual fragment, and in response to the next table read fragment request from the interrogator, the tag sends an ISO message that contains a sequence number and an authentication checksum. The authentication checksum is computed by concatenating all messages exchanged between the interrogator and tag, beginning with the message containing the initial token sent by the tag upon completing preparation of its response, and ending with the tag's final message containing the authentication checksum, except for the checksum itself. During the exchange of messages that transmit the tag's response to the interrogator, if the tag happens to detect any error, the tag sends the interrogator an ISO 18000-7 error message. The interrogator then discontinues the exchange, and notifies the application program 101 of the error.
  • When the interrogator receives the message with the tag's authentication checksum, the interrogator independently computes an authentication checksum, and compares it to the authentication checksum received from the tag, in order to verify that they are identical. If the tag's authentication checksum is verified successfully, then the security shim 201 in the interrogator reassembles the various fragments it retrieved, decrypts the result, and replaces or recreates the missing ISO headers, in order to thereby end up with the ISO message that was the tag's response. The security shim 201 then passes this ISO message to the application program 101 in the interrogator.
  • The foregoing explanation relates to an exchange that began when the interrogator 12 decided to send an ISO P2P message to a single specific tag 16. However, as discussed earlier, the interrogator 12 can also broadcast to a plurality of different tags an ISO 18000-7 broadcast table query message having embedded within it a protected broadcast table query. In particular, the embedded message is a table query directed to one of the ISO tables 117-118 that is present in each of the tags, and is sent in an envelope message that is a table query to the Broadcast Request Table 253. The original command is compressed, encrypted and fragmented in a manner similar to that shown in FIG. 8, with two differences. The first difference is that the encryption is always carried out using the read-only keyset 272 of the tags to which the message is directed. It will be noted that these tags all need to share the same read-only keyset 272, but the other keysets 271, 273 and 274 can all be different and unique in each tag. The second difference relates to the compressed ISO headers in the tunneled message.
  • More specifically, the ISO headers of the tunneled message include a packet options field, which in turn contains a communication type bit. When the security shim 201 intercepts the message prepared by the application program 101, this communication type bit will be a binary “0”, to indicate that the communication is a broadcast communication. But during the process of compressing the ISO headers, the security shim 201 in the interrogator generates a random bit that is referred to here as the collection query random bit “CQRB”. The security shim 201 saves the CQRB for later use, and also stores this bit in the communication type bit of the packet options field in the compressed ISO headers, in place of the binary “0” that the interrogator 12 put there.
  • FIG. 11 is a diagram showing how the fragments of the original table query message are sent in several successive ISO table query messages 446-449 that are directed to the Broadcast Request Table 253 in the tags. The transmission of the messages 446-449 conforms to the ISO 18000-7 standard, and is therefore discussed here only briefly. The interrogator 12 successively transmits each of the messages 446-449, without receiving any response from any of the multiple tags.
  • The final message 449 contains authentication information 456, including a final sequence number, and an authentication checksum. The checksum is computed by concatenating all of the information in all of the messages 446-449, except for the checksum itself. The checksum is computed according to the message authentication algorithm of the protection suite identified in the cryptographic information TLV that is embedded within the fragment F1 in the first message 446, using the read-only keyset 272.
  • As each tag 16 is receiving the messages 446-449, the tag's security shim 202 monitors the ISO 18000-7 query collection command sequence numbers in those messages, using the table 279 (FIG. 5). In particular, if a received sequence number is less than or equal to the sequence number currently stored in the table 279 for interrogator 12, the security shim flags an error. Otherwise, the security shim 202 replaces the sequence number in the table 279 with the new sequence number. When the messages 446-449 have all been properly received, the tag locally computes its own authentication checksum for these messages, and compares it to the authentication checksum received in the final message from the interrogator, in order to verify that they are identical. If this authentication fails, then the tag discards the messages. But if the sequence and authentication information is all correct, then the security shim 202 in the tag decrypts and reassembles the original table query message. As part of the reassembly of the original message, and in particular as the compressed ISO headers are reconstructed, the security shim 202 saves the received CQRB bit for later use, and sets the communication type bit of the packet options field in the reconstructed headers to a binary “0”. The security shim 202 then passes the reconstructed message on to the application program 111 of the tag.
  • In due course, and in a similar manner, the interrogator will transmit to all the tags a broadcast message containing a collection query command. When the security shim 202 in the tag passes this message on the tag's application program 111, the application program 111 will generate an ISO 18000-7 compliant reply message. The ISO headers of this message contain a tag status field, which in turn includes a “service bit” that represents tag's reply to the query. This ISO message is intercepted by the security shim 202 in the tag, and the security shim performs an exclusive or (XOR) between the service bit and the CQRB bit, and substitutes the result for the service bit. Then without further change or tunneling, the security shim 202 transmits the modified ISO message to the interrogator 12. Although this ISO message is not encrypted or tunneled, the true value of the service bit cannot be determined.
  • When the security shim 201 in the interrogator 12 receives this ISO message, it takes the modified service bit from the tag status field in the ISO headers, and carries out an exclusive or (XOR) between this modified service bit and the previously-saved CQRB bit, in order to thereby recover the original value of the service bit. The security shim substitutes this recovered original service bit for the modified service bit in the ISO headers of the message, and then passes the message on to the application program 101 in the interrogator.
  • As mentioned earlier, the ISO 18000-7 standard has provisions for the interrogator 12 to transmit to multiple tags a broadcast request for a universal data block (UDB), expecting that each tag will then prepare and return a UDB. In addition, the ISO 18000-7 standard has provisions for the interrogator 12 to transmit to one selected tag a P2P request for a UDB, and then only the selected tag will prepare and return a UDB. For the purpose of this discussion, it is assumed that, in the disclosed embodiment of FIG. 5, the application program 101 in the interrogator 12 generates the broadcast ISO message for UDB collection. The security shim 201 does not apply any encryption or other form of security to that message. Instead, the security shim 201 transmits the message at 28 without any change. On the other hand, when each tag 16 responds, the tag's security shim 202 encrypts certain information in the UDB data that is being returned, as briefly mentioned earlier. This is explained in more detail below, with reference to FIG. 12.
  • More specifically, FIG. 12 is a diagram showing an ISO message 501 that contains one or more protected blocks 506 of UDB data, and also one or more authentication blocks 508. The UDB blocks 506 and the authentication blocks 508 are provided in pairs. That is, each UDB block 506 is associated with a respective different authentication block 508. As discussed earlier in association with FIG. 5, the security shim 202 in the tag maintains a UDB recipient list 226, and in the disclosed embodiment this list contains at least two UDB access control objects 227 and 231. The UDB message 501 contains a respective UDB block 506 for each access control object in the list 226, and also contains a corresponding authentication block 508 for each access control object.
  • One of the UDB blocks 506 is shown in more detail in the upper portion of FIG. 12. It includes a section 516 of UDB data, and this section 516 contains one or more data elements that are each configured in a TLV format. As discussed above in association with FIGS. 5 and 6, the application program 111 responds to a UDB request by collecting all of the data elements in the tag that could possibly be returned in reply to a UDB request. As discussed in association with FIG. 6, each UDB access control object in the list 226 includes UDB access information, such as that shown at 229 or 233 in FIG. 6. The UDB access information defines which of the various UDB data elements the associated recipient is entitled to receive. In this example, as discussed above in association with FIG. 6, the UDB access information 229 for one recipient is different from the UBD access information 233 for another recipient. Thus, the section 516 in one UDB block 506 will contain one set of data elements specified by one recipient's UDB access information 229, whereas a different UDB block 506 will contain a different set of data elements identified by the other recipient's UDB access information 233. Moreover, as discussed above in association with FIG. 6, the UDB protection status information 241 will be used to determine whether or not each data element in each UDB block 506 will be protected by encryption.
  • In FIG. 12, each UDB block 506 includes a field 521 that contains a UDB sequence number in TLV format, and a further field 522 that contains tag identification information in TLV format. The tag identification information at 522 includes both the tag manufacturer identification 122 (FIG. 5) and also the tag serial number 124. The fields 516, 521 and 522 are encrypted by the security shim 202, using a randomly generated encryption key that is different for each UDB block 506. The random encryption key is then encrypted using the respective public key 228 or 232 (FIG. 5) of the intended recipient of the particular UDB block 506, and this encrypted key is placed in a field 524 of the block 506, in TLV format. The recipient of the block will have a private key corresponding to the public key 228 or 232, and will thus be able to decrypt the field 524 in order to retrieve the random key. The recipient can then use this random key to decrypt and authenticate the fields 516 and 521-522.
  • Each UDB block 506 also includes several other fields 526-530. The fields 526 and 527 are type and length information for the TLV format of the entire UDB block 506. The field 528 is a recipient identification in TLV format. In the disclosed embodiment, the recipient identification is the “distinguished name” from the particular recipient's X.509 certificate 225 or 230 (FIG. 5). The field 529 contains cryptographic information that will be needed by the recipient in order to decrypt the encrypted portions of the UDB 506. The field 530 contains authentication information in the form of a cryptographic checksum of all of the other fields (A1) in that particular UDB block 506, computed according to the authentication technique specified by the protection suite identified in the cryptographic information 529, and using the random key that appears in encrypted form in field 524.
  • The lower portion of FIG. 12 shows one of the authentication blocks 508 in greater detail. In the disclosed embodiment, each authentication block 508 includes six fields 541-546. The field 546 contains an authentication checksum that is based on all information (A2) in the message 501 other than the authentication blocks 508, as well as everything (A3) in this particular authentication block 508, other than the field 546 itself. The fields 541 and 542 contain type and length information for the TLV format of the entire authentication block 508. The field 543 contains a recipient identification which is the same as that in the field 528 of the corresponding UDB block 506. The field 544 contains a cryptographic information TLV of the type shown in FIG. 9, part of which is an identification of the authentication method used to generate the authentication checksum in the field 546. The authentication checksum is generated with a random key. This random key is then encrypted using the public key 228 or 232 from the digital certificate of the intended recipient, and placed in a field 545 of the authenticaion block 508.
  • The ISO message 501 of FIG. 12 containing UDB information is not itself encrypted and/or tunneled, because each of the UDB blocks 506 in this message 501 have portions that have already been separately encrypted. If the UDB blocks 506 and authentication blocks 508 have a collective size that is too large to be sent in a single ISO 18000-7 message, then this UDB “payload” is broken up into two or more segments in a manner specified by the ISO 18000-7 protocol, and the segments are sent in separate messages. Since persons skilled in the art are familiar with how, under the ISO 18000-7 standard, a UDB payload is to be segmented and how the segments are to be separately transmitted, that process is not shown and described in detail here. It is assumed for the sake of this discussion that the UDB payload is not sufficiently large to require segmentation. Consequently, the message shown at 501 will be wirelessly transmitted at 28 in the format shown at 501.
  • The security shim 201 in the interrogator 12 will receive the message 501, and then pass it on without change to the application program 101, which will then forward it on to each of the intended recipients. For example, assume that the users 22 and 23 in FIG. 5 respectively correspond to the UDB access control objects 227 and 231 in the tag 16. The application program 101 would forward the entire message 501 through the network 18 to each of the users 22 and 23. User 22 will have a private key that corresponds to the public key 228 in the certificate 225, and will thus have cryptographic access to one UDB block 506 and the associated authentication block 508. The user 23 will have a different private key that corresponds to the public key 232 in the certificate 230, and will thus have cryptographic access to a different UDB block 506 and the associated authentication block 508. The user 22 will be able to verify the two authentication checksums 530 and 546 in its pair of blocks 506 and 508, and the user 23 will be able to separately verify the authentication checksums in the fields 530 and 546 of its pair of blocks 506 and 508.
  • With reference to FIG. 5, when the tag 16 is first being commissioned, the tag owner will install the security officer access control object 210 that contains the root certificate 212. At this point, the list 211 will not contain any other certificates, and the list 226 will be empty. Further, the cryptographic keysets in table 270 will not yet be defined.
  • After the tag owner installs the access control object 210 containing the root certificate 212, the next step in the commissioning procedure is for a security officer (for example the user 21) to authenticate himself to the tag, for the purpose of defining keysets 271-274 that will allow the security shims 201 and 202 to exchange protected information in the manner described above. The first task that the security officer must complete is to establish the security officer keyset 271, in a manner explained in more detail below. As this is carried out, the security shim 201 transmits information to the tag 16, using table write fragment commands that store information fragments in the P2P Request Table 251, and using table read fragment commands to read information fragments from the P2P Response Table 252, in a manner generally similar to that already described above. One difference is that, with reference to FIG. 7, the protection suite used for these particular exchanges is the NULL-NULL protection suite. In other words, the security shims 201 and 202 exchange P2P ISO messages without using any encryption or authentication. This is because the exchange of information between the security officer and the tag in this particular situation is configured to be self-protecting.
  • In more detail, FIG. 13 is a flowchart showing how a security officer can, through the interrogator 12, authenticate to the root certificate 212 in the tag 16, determine a protection suite, and establish the security officer keyset 271. This procedure begins at 571. In block 572, the security officer has the security shim 201 generate a transient random public key and a transient random private key, which are respectively shown at 316 and 317 in FIG. 5. The security officer also has the interrogator's security shim 201 generate a random number RI. The security officer then has the security shim 201 transmit selected information to the tag at 573, using the tunneling technique discussed above in association with FIGS. 8 and 10, but with the NULL-NULL protection suite (FIG. 7). The information transmitted at 573 includes the security officer's digital certificate 301 (including its embedded public key 302), the list 311 of protection suites supported by the security shim 201 in the interrogator, the transient public key 316, and the random number RI.
  • Upon receiving this information, the security shim 202 in the tag compares the protection suite list 311 from the interrogator 12 to its own protection suite list 258, in order to determine whether or not there is at least one protection suite common to both lists (other than the NULL-NULL protection suite). If there is no common protection suite, then the security shim 202 terminates its participation in the transaction, as indicated at 577. Otherwise, the security shim 202 proceeds to block 578, where it checks to see if the digital certificate 301 from the security officer is valid. For example, the digital certificate 301 specifies a range of dates within which it is valid, and the security shim 202 can verify that the current date maintained in the tag using clock 52 (FIG. 1) is within the range of dates specified by the certificate. The security shim 202 can also check the integrity of the certificate by verifying the issuer's signature, using the public key 302 from the security officer's digital certificate 301. If the security shim 202 determines that there is a problem with the digital certificate 301 of the security officer, the security shim terminates the transaction at 577.
  • Otherwise, at block 581, the security shim 202 selects one protection suite that is common to both of the lists 311 and 258 (other than the NULL-NULL protection suite). The security shim 202 also generates a random number RT. Then, the security shim 202 uses the transient public key 316 received from the interrogator at 573 to encrypt both the random number RT and an identification of the selected protection suite. Then, at 582, this information is transmitted back to the security shim 201 in the interrogator 12. The transfer of this information is effected by putting the information in the P2P Response Table 252, and then notifying the security shim 201 in the interrogator, so that the security shim 201 can retrieve this information from the table 252 in the manner discussed earlier. The protection suite selected by the tag at block 581 is not yet in effect, and so all of the exchanges shown in FIG. 13 are carried out using the NULL-NULL protection suite.
  • At block 583, the security shim 201 in the interrogator decrypts the information that it received at 582 from the security shim 202 in the tag. The security shim 201 then computes an authentication value HI, according to the authentication technique identified in the protection suite selected by the security shim 202 in the tag, and using the random key RT received from the security shim 202. In addition, the security shim 201 generates a further random number SALT. The security shim 201 concatenates the authentication value HI and the random number SALT, and signs the concatenated result with the private key 303 associated with the digital certificate 301. This signed information is then transmitted at 584 to the security shim 202 in the tag. Upon receiving this information, the security shim 202 uses the public key 302 that it received in the security officer's certificate 301, and verifies the signature in the information received at 584. If the signature is not valid, then the security shim 202 ends the transaction at 577.
  • Otherwise, the security shim 202 in the tag proceeds to block 587, where it locally computes its own authentication checksum HT, and then compares this to the authentication checksum HI from the interrogator, in order to verify they are identical. If they are different, then the security shim 202 terminates the transaction at 577. Otherwise, the security shim 202 proceeds to block 588, where it generates the security officer (SO) keyset 271. In this regard, the various messages received from the interrogator each include the interrogator identification code 103 (FIG. 5), and of course the security shim 202 has also received from the interrogator's security shim 201 the random numbers RI and SALT. The tag's security shim 202 concatenates (1) the random number SALT, (2) the random number RT, (3) the random number RI, (4) the tag serial number 124, (5) the tag manufacturer identification 122, and (6) the interrogator identification 103. The security shim 202 then uses this concatenated information as an input to well-known algorithm referred to in the art as PBKDF2 (Password-Based Key Derivation Function), in order to derive material that is used as the security officer keyset 271. This keyset includes both an encryption key, and an authentication key. The tag's security shim 202 saves this keyset at 271. Next, at 591, the security shim 202 sends to the interrogator's security shim 201 a message that instructs the security shim 201 to change protection suites. The security shim 202 then switches from use of the NULL-NULL protection suite to use of the protection suite selected at block 581.
  • When the interrogator's security shim 201 receives the message sent at 591, the it already has in hand all of the same information used by the tag's security shim 202 to generate the security officer keyset. Accordingly, at block 592, the interrogator's security shim 201 separately derives and saves the security officer keyset 271 in the same manner that this keyset was derived by the tag's security shim 202, in particular by concatenating the same information and then using the same PBKDF2 function. The security shim 201 in the interrogator then switches from use of the NULL-NULL protection suite to use of the protection suite selected by the tag at block 581. Thereafter, any further communications between the security officer and the tag will still be effected with tunneled messages routed through the P2P Request and Response Tables 251 and 252, but using the security officer keyset 271, and the protection suite selected at 581.
  • In this regard, the security officer can use the selected protection suite and the security officer keyset 271 to send the tag's security shim 202 a read-only keyset, which the security shim 202 stores at 272 for later use. As mentioned earlier, the security officer will normally provide this same read-only keyset to many different tags, so that broadcast messages sent to multiple tags can contain information encrypted with this keyset, and the various tags will each be able to decrypt the encrypted information.
  • The security officer can also use the security officer keyset 271 and the selected protection suite to instruct the tag's security shim 202 to generate a read/write keyset. The security shim 202 will then generate random numbers for use as the read/write keyset, store the read/write keyset at 273, and send the read/write keyset 273 back to the interrogator's security shim 201. Further, the security officer can use the security officer keyset 271 and the selected protection suite to instruct the tag's security shim 202 to generate a tag response keyset. The security shim 202 then generates random numbers for use as the tag response keyset, stores the tag response keyset at 274, and sends the tag response keyset to the interrogator's security shim 201.
  • Using the security officer keyset and the selected protection suite, the security officer can also instruct the tag's security shim 202 to invalidate all of the keysets that are currently stored in the table 270, including the security officer keyset 271. This is a two-step procedure. First, the security officer sends a message instructing the tag's security shim 202 to invalidate all of the local keysets stored in table 270. The security shim 202 then sends back a message containing a random number. The interrogator's security shim 201 then increments the random number by 1 modulo 296, and sends the result to the tag's security shim 202. The security shim 202 checks the incremented value and, if it is correct, the security shim 202 invalidates all of the keysets stored in the table 270.
  • Using the security officer keyset 271 and the selected protection suite, the security officer can optionally install additional access control objects in the tag. For example, the security officer can optionally install one or more additional security officer access control objects in the list 211, such as the certificate shown in broken lines at 220. In addition, the security officer can optionally install one or more UDB access control objects in the list 226, such as those shown in broken lines at 227 and 231. When the security officer installs an additional access control object 220 in the list 211, the tag access rights for that additional object cannot be greater than the tag access rights of the existing access control object that was used to create the security officer keyset being used by the security officer.
  • The security officer can view access control objects already installed on the tag, by sending a message that requests a list of the installed objects. In response, the tag will return a list containing the “subject name” field from the digital certificates in each of the access control objects currently installed in each of the lists 211 and 226 on the tag.
  • The security officer can use the security officer keyset 271 and the selected protection suite to optionally remove any of the access control objects that are already installed in either of the lists 211 and 226, except for the access control object 210 containing the root certificate 212. The procedure for removing an access control object is similar to that for invalidating the keysets in table 270. In particular, the security officer sends a request that a particular access control object be deleted, and the security shim 202 in the tag returns a random number. The security officer then increments the random number by 1 modulo 296, and returns the result. The tag's security shim 202 checks the incremented result and, if it is correct, the security shim deletes the specified access control object.
  • The tag 16 maintains a not-illustrated log of all attempts to authenticate to or access the tag, including not only successful attempts, but also unsuccessful attempts.
  • FIG. 14 is a diagram showing three different sites 701, 702 and 703 that are geographically spaced from each other. For the purpose of this discussion, it is assumed by way of example that the site 701 is a manufacturer's facility, that the site 702 is a shipping hub, and that the site 703 is a customer's facility. Products manufactured at the site 701 are loaded into a container 704, and the previously-described tag 16 is physically attached to the container 704. The container 704 with the tag 16 will be shipped by truck from the manufacturer's site 701 to the shipping hub 702, where the container 704 will be switched from the original truck to a further truck. The container 704 with the tag 16 will then be transported by the further truck from the site 702 to the customer's site 703, where the products will be removed from the container.
  • The site 701 has an interrogator 706, the site 702 has an interrogator 707, and the site 703 has an interrogator 708. The interrogators 706-708 are each identical to the interrogator 12 that was described earlier, but have been given different reference numerals in FIG. 14 so that they can be separately identified. The interrogators 706-708 are operatively coupled by the network 18, which has already been discussed above. The site 701 has a person 711 who serves as a security officer (SO), the site 702 has a person 712 who serves as a security officer, then the site 703 has a person 713 who serves as a security officer. With reference to FIGS. 5 and 14, it is assumed for the purpose of this discussion that, when the tag 16 is attached to the container 704 at site 701, the access control object 210 containing root certificate 212 has already been installed in the tag 16 by the tag owner. It is also assumed that, at that time, no other access control objects have been installed in either of the lists 211 and 226, and that the keysets in table 270 have not yet been established.
  • The security officer 711 at the site 701 uses the interrogator 706 to validate to the tag 16, in the manner discussed above in association with FIG. 13. As explained above, this results in the selection of a protection suite (FIG. 7), and the generation of the security officer keyset 271. The security officer 711 then proceeds to interact with the tag in order to also establish the read-only keyset 272, the read/write keyset 273 and the tag response keyset 274. The security officer 711 then distributes the read-only keyset 272 and the tag response keyset 274 to other not-illustrated persons at the site 701 who have operator status (Table 2). Further, the security officer 711 distributes the read-only keyset 272, the read/write keyset 273 and the tag response keyset 274 to other not-illustrated persons at the site 701 who have administrator status. This distribution of keysets will normally occur electronically under a secure protocol, but in some situations the keysets may be distributed in some other manner. For example, the binary values in a keyset could be converted into a printable format (for example base 64 or base 32), and then printed out. The printed information could then be given to a user (such as the user 24 in FIG. 1) who would then manually enter the information into an interrogator (for example using the manual keypad 66 of the handheld interrogator 13).
  • The security officer 711 then installs two additional security officer access control objects in the list 211. One of these is the access control object 220. If the tag receives a communication from the security officer 712 at site 702, the tag can use the certificate 221 in the object 220 to authenticate the security officer 712. The third access control certificate in the list 211 is not shown in FIG. 5, but if the tag receives a communication from the security officer 713 at site 703, the tag can use the third access control object to authenticate the security officer 713. The security officer 712 at site 702 will be provided with a security officer certificate that corresponds to the certificate 221 in the access control object 220, and that is similar in type to the security officer certificate 301. The security officer 713 at site 703 will be provided with a further security officer certificate that corresponds to the certificate in the third access control object in the list 211, and that is similar in type to the security officer certificate 301.
  • The security officer 711 may also optionally install one or more UDB access control objects in the list 226, for respective UDB recipients. For the purpose of the exemplary situation being discussed here, it is assumed that the security officer 711 installs the UDB access control object 227, and that the certificate 225 in this object indicates a UDB recipient 721 is to receive UDB information. Further, it is assumed that the security officer 711 installs the UDB access control object 231, and that the certificate 230 in this object indicates that a UDB recipient 722 is to receive UDB information. In this example, the UDB recipients 721 and 722 are each a person or entity that does not fall within any of the four security levels listed in Table 2.
  • The keysets in table 270 can remain in effect so long as the tag 16 remains at the site 701, unless local security policy specifies that they should be invalidated and replaced sooner. It is assumed for the sake of this discussion that the keysets in table 270 are permitted to remain in effect so long as the tag is at the site 701. While the tag 16 is at the site 701, persons with operator status or administrator status can interact with the tag 16. For example, a person with administrator status may install on the tag 16 a manifest (inventory) of the products that have been loaded into the associated container 704. Eventually, when the truck carrying the container 704 and tag 16 is ready to depart the site 701, the security officer 711 uses the security officer keyset 271 to instruct the tag 16 to invalidate all four of the keysets 271-274 that are stored in table 270. Alternatively, the departure gate from the site 701 could be a choke point having an interrogator or reader that automatically invalidates the keysets in table 270 on every tag departing the site 701.
  • The container 704 with tag 16 will then be transported by the truck to the shipping hub site 702. After the container 704 and tag 16 arrive at the site 702, the security officer 712 at that site will use the interrogator 707 to authenticate to the certificate 221 in the tag 16, using the technique described above in association with FIG. 13. This will result in the selection of a protection suite for use at the site 702, and also the creation of a unique security officer keyset that will be stored in the tag at 271, and used by the security officer 712 to communicate with the tag. The security officer 712 will then establish additional keysets 272-274 for use within the site 702, and will distribute these keysets to other persons at the site 702 who have operator or administrator status with respect to the tag 16.
  • Assume that, while the tag 16 is at the site 702, the tag receives through the interrogator 707 an ISO message that instructs the tag 16 to prepare and transmit UDB information. The tag 16 will then create and transmit a message of the type shown at 501 in FIG. 12, including one UDB block 506 that is based on the access control object 227 and intended for the UDB recipient 721, and a further UDB block 506 that is associated with the access control object 231 and intended for the UDB recipient 721. The message 501 will also include two authentication blocks 508, each of which is associated with a respective one of the two UDB blocks 506. Interrogator 707 will forward the message 501 through the network 18 to each of the UDB recipients 721 and 722.
  • The UDB recipient 721 has a private key that corresponds to the public key 228 in the UDB certificate 225. The recipient 721 uses that private key to decrypt the random keys received at 524 and 545 in the UDB block 506 and associated authentication block 508 that are intended for the UDB recipient 721. The recipient 721 can use the authentication information to authenticate the received message, and can access the UDB data 516. In a similar manner, the UDB recipient 722 has a private key that corresponds to the public key 232 in the UDB certificate 230. The UDB recipient 722 uses that private key to decrypt the random keys received at 524 and 545 in the UDB block 506 and associated authentication block 508 that are intended for the recipient 722. The UDB recipient 722 can use the authentication information to authenticate the received message, and can access the UDB data 516.
  • In this manner, UDB recipient 721 can access the UDB data in the message 501 for which the recipient 721 is the intended recipient, but not UDB information intended for any other recipient, such as the UDB recipient 722. Similarly, the UDB recipient 722 can access the UDB data in the message 501 for which the recipient 722 is the intended recipient, but not UDB information intended for any other recipient, such as the UDB recipient 722. It should also be noted that, as the message 501 with encrypted UDB information is passing through the network 18 from site 702 to the UDB recipients 721 and 722, the message 501 may pass through computers or systems of third parties, but those third parties will not be able to access or view any of the encrypted UDB information that is present within the message.
  • After the container 704 with the tag 16 has been shifted from the original truck to a further truck at the site 702, and when the further truck is preparing to depart the site 702, the security officer 712 will instruct the tag 16 to invalidate all of the keysets that are stored on the tag in table 270. Alternatively, the departure gate from the site 702 could be a choke point having an interrogator or reader that automatically invalidates the keysets in table 270 on every tag departing the site 702.
  • Eventually, the further truck carrying the container 704 and the tag 16 will arrive at the customer's site 703. The security officer 713 at that site will use the interrogator 708 to authenticate to the third (not-illustrated) certificate in the list 211, in order to select a protection suite and establish a security officer keyset that the tag stores at 271. The security officer 713 will also establish all the additional keysets 272-274 for use at the site 703, and distribute these additional keysets to appropriate persons at site 703. After the container 704 has been unloaded, the tag 16 will be removed from the container. A person with administrator status may remove information from the tag that is viewed as sensitive or confidential, such as the manifest or inventory for the container 704. The security officer 713 will then instruct the tag to invalidate all the keysets stored in table 270. The security officer 713 may also remove one or more of the additional access control objects that are installed in the list 211 or in the list 226, except that the security officer 713 cannot remove the access control object 210 containing the root certificate 212. When the tag is eventually returned to the tag owner, the tag owner can remove and/or replace the access control object containing the root certificate 211.
  • The RFID system 10 of FIGS. 1 and 5-14 provides a high level of security for information exchanged between an interrogator and a tag, as well as information maintained in the tag, while remaining fully compatible with the existing ISO 18000-7 standard. Moreover, the security provisions are structured so that they can be implemented with just a firmware upgrade in existing interrogators and tags, without any hardware change. Consequently, many existing interrogators and tags can be relatively easily and cheaply upgraded, while avoiding the expense of completely replacing them, or the expense and logistical problems involved in implementing hardware alterations. Avoiding the need for extra hardware in tags also avoids the increased power consumption that would be associated with added hardware, and thus helps to avoid a reduction in the period of time that a tag can operate before its battery needs to be changed or recharged.
  • Although selected embodiments have been illustrated and described in detail, it should be understood that a variety of substitutions and alterations are possible without departing from the spirit and scope of the present invention, as defined by the claims that follow.

Claims (32)

1. An apparatus comprising: a tag having a memory storing a selected digital certificate that permits secure access to said tag from externally thereof.
2. An apparatus according to claim 1,
wherein said memory of said tag stores a further digital certificate that is different from said selected digital certificate;
wherein said selected digital certificate permits a first range of secure access to said tag from externally thereof; and
wherein said second digital certificate permits a second range of secure access to said tag from externally thereof, said second range of secure access being different from said first range of secure access.
3. An apparatus according to claim 2, wherein said first and second ranges of secure access are mutually exclusive from a security perspective.
4. An apparatus according to claim 2,
wherein said selected digital certificate has associated therewith a first set of rules defining said first range of secure access; and
wherein said further digital certificate has associated therewith a second set of rules defining said second range of secure access, said first set of rules being different from said second set of rules.
5. An apparatus according to claim 2, wherein said tag can receive wireless communications that utilize said first range of secure access, and can receive wireless communications that utilize said second range of secure access.
6. An apparatus according to claim 5, wherein said wireless communications all conform to a predetermined communications protocol.
7. An apparatus according to claim 6, wherein said communications protocol is ISO 18000-7.
8. An apparatus according to claim 2, wherein said first range of secure access includes use of a first key, and said second range of secure access involves use of a second key different from said first key.
9. An apparatus according to claim 2, wherein said first range of secure access includes use of a first set of keys, and said second range of secure access involves use of a second set of keys, said second set being different from said first set.
10. An apparatus according to claim 9,
wherein said keys of said first set include first and second key subsets that provide respective different levels of secure access to said tag; and
wherein said keys of said second set include third and fourth key subsets that provide respective different levels of secure access to said tag.
11. An apparatus according to claim 1, including a part that is separate from and spaced from said tag, that has a memory storing a further digital certificate corresponding to said selected digital certificate, and that can exchange wireless communications with said tag to authenticate said further digital certificate to said selected digital certificate in order to establish secure communication between said part and said tag.
12. An apparatus according to claim 11,
wherein said part is a mobile device; and
wherein said further digital certificate was installed into said memory of said part from a portable memory device having said further digital certificate stored therein.
13. An apparatus according to claim 12, wherein said portable memory device is a smartcard.
14. A method comprising: storing in a tag a selected digital certificate that permits secure access to said tag from externally thereof.
15. A method according to claim 14, including responding to arrival of said tag at a site by establishing at least one cryptograpic key associated with said digital certificate.
16. A method according to claim 15, wherein each said cryptographic key remains valid so long as said tag is present at said site.
17. A method according to claim 15, including invalidating each said cryptographic key when said tag leaves said site.
18. A method according to claim 14, including establishing a set of cryptographic keys associated with said digital certificate, wherein said cryptographic keys include first and second key subsets that permit respective different levels of secure access to said tag.
19. A method according to claim 14, including:
responding to arrival of said tag at a first site by establishing at least one first cryptograpic key associated with said selected digital certificate;
invalidating each said first cryptographic key when said tag leaves said first site;
responding to arrival of said tag at a second site different from said first site by establishing at least one second cryptograpic key associated with said selected digital certificate and different from said each said first cryptographic key; and
invalidating each said second cryptographic key when said tag leaves said second site.
20. A method according to claim 14, including storing in said tag a further digital certificate that is different from said selected digital certificate and that permits secure access to said tag from externally thereof.
21. A method according to claim 20, wherein said storing of said further digital certificate is carried out pursuant to secure access obtained under said selected digital certificate.
22. A method according to claim 20, including:
responding to arrival of said tag at a first site by establishing at least one first cryptograpic key associated with said selected digital certificate;
invalidating each said first cryptographic key when said tag leaves said first site;
responding to arrival of said tag at a second site different from said first site by establishing at least one second cryptograpic key associated with said further digital certificate and different from each said first cryptographic key; and
invalidating each said second cryptographic key when said tag leaves said second site.
23. A method according to claim 20,
wherein said selected digital certificate permits a first range of secure access to said tag from externally thereof; and
wherein said second digital certificate permits a second range of secure access to said tag from externally thereof, said second range of secure access being different from said first range of secure access.
24. A method according to claim 23, including configuring said first and second ranges of secure access to be mutually exclusive from a security perspective.
25. A method according to claim 23, including:
associating with said selected digital certificate a first set of rules defining said first range of secure access; and
associating with said further digital certificate a second set of rules defining said second range of secure access, said first set of rules being different from said second set of rules.
26. A method according to claim 23, including causing said tag to receive wireless communications that utilize said first range of secure access, and to receive wireless communications that utilize said second range of secure access.
27. A method according to claim 26, including configuring said wireless communications to all conform to a predetermined communications protocol.
28. A method according to claim 27, including selecting ISO 18000-7 as said predetermined communications protocol.
29. A method according to claim 23, wherein said first range of secure access includes use of a first cryptographic key, and said second range of secure access involves use of a second cryptographic key that is different from said first cryptographic key.
30. A method according to claim 23, wherein said first range of secure access includes use of a first set of cryptographic keys, and said second range of secure access involves use of a second set of cryptographic keys, said second set being different from said first set.
31. A method according to claim 30,
wherein said cryptographic keys of said first set include first and second key subsets that permit respective different levels of secure access to said tag from externally thereof; and
wherein said cryptographic keys of said second set include third and fourth key subsets that permit respective different levels of secure access to said tag from externally thereof.
32. A method according to claim 14, including:
receiving said selected digital certificate from externally of said tag using a first communications protocol, and thereafter carrying out said storing of said selected digital certificate;
authenticating to said selected digital certificate a further digital certificate received by said tag from externally thereof using a second communications protocol different from said first communications protocol, and then establishing a cryptographic first keyset associated with said selected digital certificate;
responding to receipt by said tag of an externally originated communication utilizing said first keyset and said second communications protocol by establishing a cryptographic second keyset associated with said selected digital certificate, said first and second keysets being different and permitting respective different degrees of secure access to said tag from externally thereof;
responding to receipt by said tag of an externally originated communication utilizing said first keyset and said second communications protocol by storing in said tag a further digital certificate different from but of the same type as said selected digital certificate;
responding to receipt by said tag of an externally originated communication utilizing said first keyset and said second communications protocol by storing in said tag a recipient digital certificate identifying a recipient for tag data and containing a cryptographic key of the specified recipient; and
responding to receipt by said tag of an externally originated communication utilizing said second keyset and said second communications protocol by transmitting externally of said tag a communication containing tag data encrypted with said cryptographic key.
US11/968,002 2007-07-23 2007-12-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System Abandoned US20090028337A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US11/968,002 US20090028337A1 (en) 2007-07-23 2007-12-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System
EP08796353A EP2181536A2 (en) 2007-07-23 2008-07-21 Method and apparatus for providing security in a radio frequency identification system
CN200880107247A CN101803334A (en) 2007-07-23 2008-07-21 The method and apparatus of fail safe is provided in radio-frequency recognition system
KR1020107003578A KR20100035712A (en) 2007-07-23 2008-07-21 Method and apparatus for providing security in a radio frequency identification system
PCT/US2008/070614 WO2009015073A2 (en) 2007-07-23 2008-07-21 Method and apparatus for providing security in a radio frequency identification system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US95133407P 2007-07-23 2007-07-23
US11/968,002 US20090028337A1 (en) 2007-07-23 2007-12-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System

Publications (1)

Publication Number Publication Date
US20090028337A1 true US20090028337A1 (en) 2009-01-29

Family

ID=40295256

Family Applications (6)

Application Number Title Priority Date Filing Date
US11/967,951 Active 2030-06-23 US8116454B2 (en) 2007-07-23 2007-12-31 Method and apparatus for providing security in a radio frequency identification system
US11/968,002 Abandoned US20090028337A1 (en) 2007-07-23 2007-12-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System
US11/967,859 Active 2030-03-19 US8547957B2 (en) 2007-07-23 2007-12-31 Method and apparatus for providing security in a radio frequency identification system
US11/967,977 Abandoned US20090028329A1 (en) 2007-07-23 2007-12-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System
US11/967,907 Active 2030-05-21 US8204225B2 (en) 2007-07-23 2007-12-31 Method and apparatus for providing security in a radio frequency identification system
US14/016,084 Abandoned US20150067872A1 (en) 2007-07-23 2013-08-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/967,951 Active 2030-06-23 US8116454B2 (en) 2007-07-23 2007-12-31 Method and apparatus for providing security in a radio frequency identification system

Family Applications After (4)

Application Number Title Priority Date Filing Date
US11/967,859 Active 2030-03-19 US8547957B2 (en) 2007-07-23 2007-12-31 Method and apparatus for providing security in a radio frequency identification system
US11/967,977 Abandoned US20090028329A1 (en) 2007-07-23 2007-12-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System
US11/967,907 Active 2030-05-21 US8204225B2 (en) 2007-07-23 2007-12-31 Method and apparatus for providing security in a radio frequency identification system
US14/016,084 Abandoned US20150067872A1 (en) 2007-07-23 2013-08-31 Method and Apparatus for Providing Security in a Radio Frequency Identification System

Country Status (5)

Country Link
US (6) US8116454B2 (en)
EP (1) EP2181536A2 (en)
KR (1) KR20100035712A (en)
CN (1) CN101803334A (en)
WO (1) WO2009015073A2 (en)

Cited By (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090028333A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US20090320102A1 (en) * 2008-06-20 2009-12-24 At&T Corp. Methods for Distributing Information Using Secure Peer-to-Peer Communications
US20120191848A1 (en) * 2011-01-21 2012-07-26 John Peter Norair Method and apparatus for discovering people, products, and/or services via a localized wireless network
US20130113611A1 (en) * 2010-08-27 2013-05-09 Korea University Research And Business Foundation Data transmission method in passive communication system
US8788665B2 (en) 2000-03-21 2014-07-22 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US8806053B1 (en) 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
US20150110272A1 (en) * 2013-10-17 2015-04-23 Motorola Solutions, Inc. Methods, systems, and devices to reduce audio truncation during transcoding
US9077554B1 (en) 2000-03-21 2015-07-07 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US9554276B2 (en) 2010-10-29 2017-01-24 F5 Networks, Inc. System and method for on the fly protocol conversion in obtaining policy enforcement information
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US10015286B1 (en) * 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
USRE47019E1 (en) 2010-07-14 2018-08-28 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US10097616B2 (en) 2012-04-27 2018-10-09 F5 Networks, Inc. Methods for optimizing service of content requests and devices thereof
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
DE102017011588A1 (en) * 2017-12-06 2019-06-06 Giesecke+Devrient Mobile Security Gmbh Secure data transmission of user data
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US20200382305A1 (en) * 2015-12-30 2020-12-03 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11171944B2 (en) * 2016-01-29 2021-11-09 Cable Television Laboratories, Inc. Systems and methods for secure automated network attachment
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US11924192B2 (en) * 2021-11-08 2024-03-05 Cable Television Laboratories, Inc. Systems and methods for secure automated network attachment

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007041768B4 (en) * 2007-09-04 2010-03-04 Deckel Maho Pfronten Gmbh System for controlling access to a machine tool
US20100146273A1 (en) * 2008-12-04 2010-06-10 Electronics And Telecommunications Research Institute Method for passive rfid security according to security mode
SI22987A (en) * 2009-02-27 2010-08-31 Ids D.O.O. Label for contactless identification by enhanced communication between an external logical element connected to it by electro-plating and polling device as well as procedure for such communication
US8832778B2 (en) * 2009-08-04 2014-09-09 Carnegie Mellon University Methods and apparatuses for user-verifiable trusted path in the presence of malware
US8068011B1 (en) * 2010-08-27 2011-11-29 Q Street, LLC System and method for interactive user-directed interfacing between handheld devices and RFID media
US20120155349A1 (en) * 2010-11-16 2012-06-21 Zeljko Bajic Rfid applications
CN102646183A (en) * 2012-03-20 2012-08-22 无锡儒安科技有限公司 Batch authentication method and system of RFID (Radio Frequency Identification) tags
US10114939B1 (en) * 2014-09-22 2018-10-30 Symantec Corporation Systems and methods for secure communications between devices
EP3243131B1 (en) * 2015-01-09 2019-01-02 SRI International Unclonable rfid chip and method
KR20160138754A (en) * 2015-05-26 2016-12-06 삼성전기주식회사 Printed circuit board, semiconductor package and method of manufacturing the same
US9992810B2 (en) * 2015-08-26 2018-06-05 Samsung Electronics Co., Ltd Method for providing integrity protection in a dual SIM dual standby device
FR3040510B1 (en) * 2015-08-27 2018-08-10 Ingenico Group DEVICE AND METHOD FOR SECURING CONTROLS EXCHANGED BETWEEN TERMINAL AND INTEGRATED CIRCUIT
CA3034986A1 (en) 2016-09-09 2018-03-15 Socovar, Societe En Commandite Checksum-filtered decoding, checksum-aided forward error correction of data packets, forward error correction of data using bit erasure channels and sub-symbol level decoding for erroneous fountain codes
CN106534171B (en) * 2016-12-02 2020-03-10 全球能源互联网研究院有限公司 Security authentication method, device and terminal
US20190026749A1 (en) * 2017-07-18 2019-01-24 Eaton Corporation Security tag and electronic system usable with molded case circuit breakers
CN108616313A (en) * 2018-04-09 2018-10-02 电子科技大学 A kind of bypass message based on ultrasound transfer approach safe and out of sight
TWI659359B (en) * 2018-04-27 2019-05-11 慧榮科技股份有限公司 Method for controlling storage device
US11139043B2 (en) * 2019-05-20 2021-10-05 Board Of Trustees Of The University Of Alabama, For And On Behalf Of The University Of Alabama In Huntsville Systems and methods for identifying counterfeit memory
CN110300105B (en) * 2019-06-24 2022-01-04 超越科技股份有限公司 Remote key management method of network cipher machine
US20220092372A1 (en) * 2020-09-18 2022-03-24 Toshiba Tec Kabushiki Kaisha Image forming device and warning method
CN114615354A (en) * 2022-04-12 2022-06-10 支付宝(杭州)信息技术有限公司 Method and device for processing message

Citations (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3932132A (en) * 1973-07-31 1976-01-13 Olympus Optical Co., Ltd. System for detecting the particular chemical constituent of a fluid
US5640151A (en) * 1990-06-15 1997-06-17 Texas Instruments Incorporated Communication system for communicating with tags
US5956405A (en) * 1997-01-17 1999-09-21 Microsoft Corporation Implementation efficient encryption and message authentication
US6116454A (en) * 1998-10-01 2000-09-12 Caterpillar Inc. Hydraulic oil tank with integral baffle
US20020018561A1 (en) * 2000-08-02 2002-02-14 Vidicast Ltd. Data encryption and decryption using error correction methodologies
US20020029342A1 (en) * 2000-09-07 2002-03-07 Keech Winston Donald Systems and methods for identity verification for secure transactions
US20030036425A1 (en) * 2001-08-10 2003-02-20 Igt Flexible loyalty points programs
US20030037235A1 (en) * 1998-08-19 2003-02-20 Sun Microsystems, Inc. System for signatureless transmission and reception of data packets between computer networks
US20030063742A1 (en) * 2001-09-28 2003-04-03 Neufeld E. David Method and apparatus for generating a strong random number for use in a security subsystem for a processor-based device
US20030081778A1 (en) * 2001-10-31 2003-05-01 Yasufumi Tsumagari Image recording apparatus, image reproduction apparatus, and information recording medium
US20030128843A1 (en) * 2002-01-04 2003-07-10 Andrew Brown Method and apparatus for preserving a strong random number across battery replacement in a security subsystem
US20030206636A1 (en) * 2002-05-02 2003-11-06 Paul Ducharme Method and system for protecting video data
US20030220903A1 (en) * 2002-04-19 2003-11-27 Mont Marco Casassa Long-term digital storage
US20040030896A1 (en) * 2002-06-10 2004-02-12 Ken Sakamura IC card and cryptographic communication method between IC cards
US20040075551A1 (en) * 2002-10-02 2004-04-22 Marino Francis C. Method and apparatus for filtering non-essential messages in a disarmed security system
US20040079922A1 (en) * 2001-02-08 2004-04-29 Osamu Yokokouji Liquid crystal composition containing an optically active compound and liquid crystal electro-optical element
US20040085446A1 (en) * 2002-10-30 2004-05-06 Park Ho-Sang Method for secured video signal transmission for video surveillance system
US20040111625A1 (en) * 2001-02-14 2004-06-10 Duffy Dominic Gavan Data processing apparatus and method
US20040233040A1 (en) * 2002-11-23 2004-11-25 Kathleen Lane Secure personal RFID documents and method of use
US20050086479A1 (en) * 2003-09-03 2005-04-21 France Telecom System and method for providing services
US20050108020A1 (en) * 2002-01-07 2005-05-19 Shauli Lehavi System and a method for accerating communication between client and an email server
US20050149442A1 (en) * 2002-03-20 2005-07-07 Research In Motion Limited Certificate information storage system and method
US20050229006A1 (en) * 2002-07-23 2005-10-13 De Moura Eduardo R Digital sealer apparatus
US20050246292A1 (en) * 2000-04-14 2005-11-03 Branko Sarcanin Method and system for a virtual safe
US20050259823A1 (en) * 2001-02-28 2005-11-24 George Apostol Jr Security system with an intelligent dma controller
US20060015729A1 (en) * 2004-06-30 2006-01-19 Sbc Knowledge Ventures, G.P. Automatic digital certificate discovery and management
US20060018485A1 (en) * 2004-07-23 2006-01-26 Diefenderfer Kristopher G Secure communication protocol
US20060018283A1 (en) * 2000-12-22 2006-01-26 Lewis Allan D Wireless router system and method
US20060046842A1 (en) * 2001-08-10 2006-03-02 Igt Ticket redemption using encrypted biometric data
US20060054682A1 (en) * 2004-09-07 2006-03-16 Carlos De La Huerga Method and system for tracking and verifying medication
US7019639B2 (en) * 2003-02-03 2006-03-28 Ingrid, Inc. RFID based security network
US20060085848A1 (en) * 2004-10-19 2006-04-20 Intel Corporation Method and apparatus for securing communications between a smartcard and a terminal
US20060161791A1 (en) * 2005-01-19 2006-07-20 Bennett Charles H Access-controlled encrypted recording system for site, interaction and process monitoring
US20060169771A1 (en) * 2005-01-31 2006-08-03 George Brookner Proximity validation system and method
US20060197651A1 (en) * 2005-03-02 2006-09-07 Samsung Electronics Co., Ltd RFID reader and RFID tag using UHF band and action methods thereof
US20060206710A1 (en) * 2005-03-11 2006-09-14 Christian Gehrmann Network assisted terminal to SIM/UICC key establishment
US20060230266A1 (en) * 2005-03-30 2006-10-12 Oracle International Corporation Secure communications across multiple protocols
US20060238353A1 (en) * 2005-03-29 2006-10-26 Cox James N RFID conveyor system
US20060258289A1 (en) * 2005-05-12 2006-11-16 Robin Dua Wireless media system and player and method of operation
US20060290504A1 (en) * 2005-06-28 2006-12-28 Chih-Hsin Wang RF tags affixed in manufactured elements
US20070013481A1 (en) * 2005-06-23 2007-01-18 Savi Technology, Inc. Method and apparatus for battery power conservation in tags
US20070028099A1 (en) * 2003-09-11 2007-02-01 Bamboo Mediacasting Ltd. Secure multicast transmission
US7183924B1 (en) * 2005-10-13 2007-02-27 Hewlett-Packard Development Company, L.P. Storing configuration information and a service record for an item in an RFID tag
US20070109124A1 (en) * 2003-04-01 2007-05-17 Mi Kyoung Park Contactless type communication tag, portable tag reader for verifying a genuine article, and method for providing information of whether an article is genuine or not
US20070210923A1 (en) * 2005-12-09 2007-09-13 Butler Timothy P Multiple radio frequency network node rfid tag
US20070271113A1 (en) * 2001-08-10 2007-11-22 Igt Dynamic Casino Tracking And Optimization
US20070276958A1 (en) * 2006-05-26 2007-11-29 International Business Machines Corporation System, method and program for encryption during routing
US20080012473A1 (en) * 2006-07-12 2008-01-17 Canon Kabushiki Kaisha Organic electroluminescence device
US20080068137A1 (en) * 2005-11-10 2008-03-20 Electronics And Telecommunications Research Institute Apparatus and method for unifying multiple radio frequency idenfications
US20080104392A1 (en) * 2006-10-26 2008-05-01 Fujitsu Limited Information access system, reader/writer device and contactless information storage device
US20080130661A1 (en) * 2004-04-28 2008-06-05 Yuanchuang Xintong Technology Of Telecom (Beljing) Co., Ltd. System and Communication Method of Ip Telecommunication Network and its Application
US7388481B1 (en) * 2004-09-22 2008-06-17 At&T Corp. Method and apparatus for asset management in an open environment
US20080170695A1 (en) * 2006-06-09 2008-07-17 Adler Joseph A Method and Apparatus to Provide Authentication and Privacy with Low Complexity Devices
US20080186174A1 (en) * 2007-02-02 2008-08-07 Sensormatic Electronics Corporation Item level inventory with a radio frequency identification (RFID) system
US20080216168A1 (en) * 1998-10-30 2008-09-04 Virnetx, Inc. Method for establishing secure communication link between computers of virtual private network
US20080231454A1 (en) * 2007-03-23 2008-09-25 Diamond Arrow Communications L.L.C. Cargo Container Monitoring Device
US20080285495A1 (en) * 2007-05-15 2008-11-20 Conexant Systems Inc. Systems and Methods for Communicating to a Disassociated Station in a Protected Network
US20090028334A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US7512799B1 (en) * 1999-03-05 2009-03-31 Getthere Inc. System and method for accessing a remote server from an intranet with a single sign-on
US7570636B2 (en) * 2004-06-29 2009-08-04 Damaka, Inc. System and method for traversing a NAT device for peer-to-peer hybrid communications
US7623516B2 (en) * 2004-06-29 2009-11-24 Damaka, Inc. System and method for deterministic routing in a peer-to-peer hybrid communications network
US20100030633A1 (en) * 2001-07-10 2010-02-04 American Express Travel Related Services Company, Inc. System for biometric security using a fob
US7702107B1 (en) * 2005-07-27 2010-04-20 Messing John H Server-based encrypted messaging method and apparatus
US7778187B2 (en) * 2004-06-29 2010-08-17 Damaka, Inc. System and method for dynamic stability in a peer-to-peer hybrid communications network
US7879111B2 (en) * 2006-11-02 2011-02-01 Sony Corporation System and method for RFID transfer of MAC, keys
US7961828B2 (en) * 2004-10-06 2011-06-14 Motorola Mobility, Inc. Sync bursts frequency offset compensation
US7971253B1 (en) * 2006-11-21 2011-06-28 Airtight Networks, Inc. Method and system for detecting address rotation and related events in communication networks
US20110202609A1 (en) * 2010-02-15 2011-08-18 Damaka, Inc. System and method for strategic routing in a peer-to-peer environment
US20110231917A1 (en) * 2010-03-19 2011-09-22 Damaka, Inc. System and method for providing a virtual peer-to-peer environment
US20110238862A1 (en) * 2010-03-29 2011-09-29 Damaka, Inc. System and method for session sweeping between devices
US8049594B1 (en) * 2004-11-30 2011-11-01 Xatra Fund Mx, Llc Enhanced RFID instrument security
US20110270932A1 (en) * 2010-04-29 2011-11-03 Damaka, Inc. System and method for peer-to-peer media routing using a third party instant messaging system for signaling
US20110291803A1 (en) * 2010-05-27 2011-12-01 Zeljko Bajic Rfid security and mobility architecture
US20110307556A1 (en) * 2004-06-29 2011-12-15 Damaka, Inc. System and method for data transfer in a peer-to-peer hybrid communication network
US20110310886A1 (en) * 2010-06-18 2011-12-22 Damaka, Inc. System and method for transferring a call between endpoints in a hybrid peer-to-peer network
US20110317834A1 (en) * 2010-06-23 2011-12-29 Damaka, Inc. System and method for secure messaging in a hybrid peer-to-peer network
US20120005723A1 (en) * 2004-06-29 2012-01-05 Damaka, Inc. System and method for concurrent sessions in a peer-to-peer hybrid communications network
US20120054276A1 (en) * 2010-08-25 2012-03-01 Damaka, Inc. System and method for shared session appearance in a hybrid peer-to-peer environment
US20120078609A1 (en) * 2010-09-24 2012-03-29 Damaka, Inc. System and method for language translation in a hybrid peer-to-peer environment
US20120087302A1 (en) * 2010-10-11 2012-04-12 Damaka, Inc. System and method for a reverse invitation in a hybrid peer-to-peer environment

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US28329A (en) * 1860-05-15 Improvement in plows
US28337A (en) * 1860-05-22 Improvement in clevises for plows
US28078A (en) * 1860-05-01 Pebfobatiltg-btrle fob pbesttebs
US28333A (en) * 1860-05-15 Emil trittin
US5600723A (en) 1994-12-23 1997-02-04 Alliedsignal Inc. Cryptographically secure electric fuel pump system
US5995630A (en) 1996-03-07 1999-11-30 Dew Engineering And Development Limited Biometric input with encryption
US6131162A (en) 1997-06-05 2000-10-10 Hitachi Ltd. Digital data authentication method
US6615175B1 (en) 1999-06-10 2003-09-02 Robert F. Gazdzinski “Smart” elevator system and method
US7711565B1 (en) 1999-06-10 2010-05-04 Gazdzinski Robert F “Smart” elevator system and method
US7093693B1 (en) 1999-06-10 2006-08-22 Gazdzinski Robert F Elevator access control system and method
US7151831B2 (en) 2001-06-06 2006-12-19 Sony Corporation Partial encryption and PID mapping
US9031880B2 (en) * 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
US7705732B2 (en) * 2001-07-10 2010-04-27 Fred Bishop Authenticating an RF transaction using a transaction counter
US7305700B2 (en) 2002-01-08 2007-12-04 Seven Networks, Inc. Secure transport for mobile communication network
US7783035B2 (en) 2002-08-30 2010-08-24 Adaptec, Inc. Systems and methods for implementing host-based security in a computer network
US6726099B2 (en) * 2002-09-05 2004-04-27 Honeywell International Inc. RFID tag having multiple transceivers
KR100512064B1 (en) 2003-04-01 2005-09-26 (주)브랜드인칩 contactless type communication tag and portable tag reader for verifying a genuine article
US7512779B2 (en) * 2003-04-22 2009-03-31 Alcatel Lucent Apparatus, and associated method, for communicating signaling data in secure form in a signaling network
US7860727B2 (en) 2003-07-17 2010-12-28 Ventana Medical Systems, Inc. Laboratory instrumentation information management and control network
EP1665626B1 (en) 2003-08-25 2016-11-16 BlackBerry Limited System and method for securing wireless data
EP1513040B1 (en) 2003-09-03 2006-12-20 France Telecom System and method for distributing content access data
ES2360701T3 (en) * 2003-10-02 2011-06-08 Given Imaging Ltd. SYSTEM AND PROCEDURE FOR THE PRESENTATION OF DATA FLOWS.
US7826614B1 (en) 2003-11-05 2010-11-02 Globalfoundries Inc. Methods and apparatus for passing initialization vector information from software to hardware to perform IPsec encryption operation
JP4209761B2 (en) 2003-12-10 2009-01-14 株式会社ケンウッド Wireless communication system for business wireless network and wireless terminal thereof
JP4607567B2 (en) 2004-01-09 2011-01-05 株式会社リコー Certificate transfer method, certificate transfer apparatus, certificate transfer system, program, and recording medium
CA2561335C (en) 2004-04-08 2013-03-19 International Business Machines Corporation Method and system for linking certificates to signed files
US7245213B1 (en) * 2004-05-24 2007-07-17 Impinj, Inc. RFID readers and RFID tags exchanging encrypted password
US8045697B1 (en) * 2004-06-02 2011-10-25 Nortel Networks Limited Method and apparatus for interfacing a customer with a call center
US20080183722A1 (en) * 2004-10-13 2008-07-31 Robert Lane Registration System
US7627896B2 (en) 2004-12-24 2009-12-01 Check Point Software Technologies, Inc. Security system providing methodology for cooperative enforcement of security policies during SSL sessions
US7253594B2 (en) 2005-01-19 2007-08-07 Texas Instruments Incorporated Reducing power/area requirements to support sleep mode operation when regulators are turned off
US7298268B2 (en) * 2005-05-17 2007-11-20 Intermec Ip Corp. Read authentication method and system for securing data stored on RFID tags
US8189786B2 (en) 2005-05-25 2012-05-29 Zenith Electronics Llc Encryption system
US8322608B2 (en) 2005-08-15 2012-12-04 Assa Abloy Ab Using promiscuous and non-promiscuous data to verify card and reader identity
US7407110B2 (en) * 2005-08-15 2008-08-05 Assa Abloy Ab Protection of non-promiscuous data in an RFID transponder
US7654444B2 (en) 2005-09-19 2010-02-02 Silverbrook Research Pty Ltd Reusable sticker
JP4581955B2 (en) * 2005-10-04 2010-11-17 ソニー株式会社 Content transmission apparatus, content transmission method, and computer program
US8947233B2 (en) 2005-12-09 2015-02-03 Tego Inc. Methods and systems of a multiple radio frequency network node RFID tag
US8390456B2 (en) 2008-12-03 2013-03-05 Tego Inc. RFID tag facility with access to external devices
US8279065B2 (en) 2005-12-09 2012-10-02 Tego Inc. Methods and systems of a multiple radio frequency network node RFID tag
CN100571125C (en) * 2005-12-30 2009-12-16 上海贝尔阿尔卡特股份有限公司 A kind of method and device that is used for secure communication between subscriber equipment and internal network
US9137012B2 (en) * 2006-02-03 2015-09-15 Emc Corporation Wireless authentication methods and apparatus
EP1821538A1 (en) 2006-02-15 2007-08-22 Irdeto Access B.V. Method and system providing scrambled content
JP2007251348A (en) 2006-03-14 2007-09-27 Toshiba Corp Content decoding device
US7450010B1 (en) * 2006-04-17 2008-11-11 Tc License Ltd. RFID mutual authentication verification session
US8301890B2 (en) 2006-08-10 2012-10-30 Inside Secure Software execution randomization
US7458139B2 (en) * 2006-09-22 2008-12-02 Kyokutoh Co., Ltd Tip dresser
US7868761B2 (en) * 2006-10-31 2011-01-11 Neocatena Networks Inc. RFID security system and method
US7870601B2 (en) 2006-11-16 2011-01-11 Nokia Corporation Attachment solution for multi-access environments
EP2115563A2 (en) 2006-12-06 2009-11-11 Fusion Multisystems, Inc. Apparatus, system, and method for managing data in a storage device with an empty data token directive
US8290157B2 (en) * 2007-02-20 2012-10-16 Sony Corporation Identification of a compromised content player
US20080231438A1 (en) 2007-03-23 2008-09-25 Diamond Arrow Communications L.L.C. Cargo Container Monitoring System
JP5525133B2 (en) 2008-01-17 2014-06-18 株式会社日立製作所 System and method for digital signature and authentication
US8174362B2 (en) * 2008-03-06 2012-05-08 Round Rock Research, Llc Methods and apparatuses to secure data transmission in RFID systems

Patent Citations (90)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3932132A (en) * 1973-07-31 1976-01-13 Olympus Optical Co., Ltd. System for detecting the particular chemical constituent of a fluid
US5640151A (en) * 1990-06-15 1997-06-17 Texas Instruments Incorporated Communication system for communicating with tags
US5686902A (en) * 1990-06-15 1997-11-11 Texas Instruments Incorporated Communication system for communicating with tags
US5956405A (en) * 1997-01-17 1999-09-21 Microsoft Corporation Implementation efficient encryption and message authentication
US20030037235A1 (en) * 1998-08-19 2003-02-20 Sun Microsystems, Inc. System for signatureless transmission and reception of data packets between computer networks
US6116454A (en) * 1998-10-01 2000-09-12 Caterpillar Inc. Hydraulic oil tank with integral baffle
US20080216168A1 (en) * 1998-10-30 2008-09-04 Virnetx, Inc. Method for establishing secure communication link between computers of virtual private network
US7512799B1 (en) * 1999-03-05 2009-03-31 Getthere Inc. System and method for accessing a remote server from an intranet with a single sign-on
US20050246292A1 (en) * 2000-04-14 2005-11-03 Branko Sarcanin Method and system for a virtual safe
US20020018561A1 (en) * 2000-08-02 2002-02-14 Vidicast Ltd. Data encryption and decryption using error correction methodologies
US20020029342A1 (en) * 2000-09-07 2002-03-07 Keech Winston Donald Systems and methods for identity verification for secure transactions
US20090135765A1 (en) * 2000-12-22 2009-05-28 Lewis Allan D Wireless router system and method
US20060018283A1 (en) * 2000-12-22 2006-01-26 Lewis Allan D Wireless router system and method
US20040079922A1 (en) * 2001-02-08 2004-04-29 Osamu Yokokouji Liquid crystal composition containing an optically active compound and liquid crystal electro-optical element
US20040111625A1 (en) * 2001-02-14 2004-06-10 Duffy Dominic Gavan Data processing apparatus and method
US20050259823A1 (en) * 2001-02-28 2005-11-24 George Apostol Jr Security system with an intelligent dma controller
US20100030633A1 (en) * 2001-07-10 2010-02-04 American Express Travel Related Services Company, Inc. System for biometric security using a fob
US7988038B2 (en) * 2001-07-10 2011-08-02 Xatra Fund Mx, Llc System for biometric security using a fob
US20070271113A1 (en) * 2001-08-10 2007-11-22 Igt Dynamic Casino Tracking And Optimization
US20030036425A1 (en) * 2001-08-10 2003-02-20 Igt Flexible loyalty points programs
US20060046842A1 (en) * 2001-08-10 2006-03-02 Igt Ticket redemption using encrypted biometric data
US20030063742A1 (en) * 2001-09-28 2003-04-03 Neufeld E. David Method and apparatus for generating a strong random number for use in a security subsystem for a processor-based device
US20030081778A1 (en) * 2001-10-31 2003-05-01 Yasufumi Tsumagari Image recording apparatus, image reproduction apparatus, and information recording medium
US20030128843A1 (en) * 2002-01-04 2003-07-10 Andrew Brown Method and apparatus for preserving a strong random number across battery replacement in a security subsystem
US20050108020A1 (en) * 2002-01-07 2005-05-19 Shauli Lehavi System and a method for accerating communication between client and an email server
US20050149442A1 (en) * 2002-03-20 2005-07-07 Research In Motion Limited Certificate information storage system and method
US20030220903A1 (en) * 2002-04-19 2003-11-27 Mont Marco Casassa Long-term digital storage
US20030206636A1 (en) * 2002-05-02 2003-11-06 Paul Ducharme Method and system for protecting video data
US20040030896A1 (en) * 2002-06-10 2004-02-12 Ken Sakamura IC card and cryptographic communication method between IC cards
US20050229006A1 (en) * 2002-07-23 2005-10-13 De Moura Eduardo R Digital sealer apparatus
US20040075551A1 (en) * 2002-10-02 2004-04-22 Marino Francis C. Method and apparatus for filtering non-essential messages in a disarmed security system
US20040085446A1 (en) * 2002-10-30 2004-05-06 Park Ho-Sang Method for secured video signal transmission for video surveillance system
US20040233040A1 (en) * 2002-11-23 2004-11-25 Kathleen Lane Secure personal RFID documents and method of use
US7019639B2 (en) * 2003-02-03 2006-03-28 Ingrid, Inc. RFID based security network
US20070109124A1 (en) * 2003-04-01 2007-05-17 Mi Kyoung Park Contactless type communication tag, portable tag reader for verifying a genuine article, and method for providing information of whether an article is genuine or not
US20050086479A1 (en) * 2003-09-03 2005-04-21 France Telecom System and method for providing services
US20070028099A1 (en) * 2003-09-11 2007-02-01 Bamboo Mediacasting Ltd. Secure multicast transmission
US20080130661A1 (en) * 2004-04-28 2008-06-05 Yuanchuang Xintong Technology Of Telecom (Beljing) Co., Ltd. System and Communication Method of Ip Telecommunication Network and its Application
US20090262742A1 (en) * 2004-06-29 2009-10-22 Damaka, Inc. System and method for traversing a nat device for peer-to-peer hybrid communications
US7778187B2 (en) * 2004-06-29 2010-08-17 Damaka, Inc. System and method for dynamic stability in a peer-to-peer hybrid communications network
US7570636B2 (en) * 2004-06-29 2009-08-04 Damaka, Inc. System and method for traversing a NAT device for peer-to-peer hybrid communications
US7623516B2 (en) * 2004-06-29 2009-11-24 Damaka, Inc. System and method for deterministic routing in a peer-to-peer hybrid communications network
US20120005723A1 (en) * 2004-06-29 2012-01-05 Damaka, Inc. System and method for concurrent sessions in a peer-to-peer hybrid communications network
US20110307556A1 (en) * 2004-06-29 2011-12-15 Damaka, Inc. System and method for data transfer in a peer-to-peer hybrid communication network
US20060015729A1 (en) * 2004-06-30 2006-01-19 Sbc Knowledge Ventures, G.P. Automatic digital certificate discovery and management
US20060018485A1 (en) * 2004-07-23 2006-01-26 Diefenderfer Kristopher G Secure communication protocol
US20060054682A1 (en) * 2004-09-07 2006-03-16 Carlos De La Huerga Method and system for tracking and verifying medication
US20120081227A1 (en) * 2004-09-22 2012-04-05 Cahn Robert S Method and apparatus for asset management in an open environment
US7388481B1 (en) * 2004-09-22 2008-06-17 At&T Corp. Method and apparatus for asset management in an open environment
US7961828B2 (en) * 2004-10-06 2011-06-14 Motorola Mobility, Inc. Sync bursts frequency offset compensation
US20060085848A1 (en) * 2004-10-19 2006-04-20 Intel Corporation Method and apparatus for securing communications between a smartcard and a terminal
US8049594B1 (en) * 2004-11-30 2011-11-01 Xatra Fund Mx, Llc Enhanced RFID instrument security
US20120013448A1 (en) * 2004-11-30 2012-01-19 Xatra Fund Mx, Llc System and method for enhanced rfid instrument security
US20060161791A1 (en) * 2005-01-19 2006-07-20 Bennett Charles H Access-controlled encrypted recording system for site, interaction and process monitoring
US20060169771A1 (en) * 2005-01-31 2006-08-03 George Brookner Proximity validation system and method
US20060197651A1 (en) * 2005-03-02 2006-09-07 Samsung Electronics Co., Ltd RFID reader and RFID tag using UHF band and action methods thereof
US20060206710A1 (en) * 2005-03-11 2006-09-14 Christian Gehrmann Network assisted terminal to SIM/UICC key establishment
US20060238353A1 (en) * 2005-03-29 2006-10-26 Cox James N RFID conveyor system
US20060230266A1 (en) * 2005-03-30 2006-10-12 Oracle International Corporation Secure communications across multiple protocols
US20060258289A1 (en) * 2005-05-12 2006-11-16 Robin Dua Wireless media system and player and method of operation
US20070013481A1 (en) * 2005-06-23 2007-01-18 Savi Technology, Inc. Method and apparatus for battery power conservation in tags
US20060290504A1 (en) * 2005-06-28 2006-12-28 Chih-Hsin Wang RF tags affixed in manufactured elements
US7702107B1 (en) * 2005-07-27 2010-04-20 Messing John H Server-based encrypted messaging method and apparatus
US7183924B1 (en) * 2005-10-13 2007-02-27 Hewlett-Packard Development Company, L.P. Storing configuration information and a service record for an item in an RFID tag
US20080068137A1 (en) * 2005-11-10 2008-03-20 Electronics And Telecommunications Research Institute Apparatus and method for unifying multiple radio frequency idenfications
US20070210923A1 (en) * 2005-12-09 2007-09-13 Butler Timothy P Multiple radio frequency network node rfid tag
US20070276958A1 (en) * 2006-05-26 2007-11-29 International Business Machines Corporation System, method and program for encryption during routing
US20080170695A1 (en) * 2006-06-09 2008-07-17 Adler Joseph A Method and Apparatus to Provide Authentication and Privacy with Low Complexity Devices
US20080012473A1 (en) * 2006-07-12 2008-01-17 Canon Kabushiki Kaisha Organic electroluminescence device
US20080104392A1 (en) * 2006-10-26 2008-05-01 Fujitsu Limited Information access system, reader/writer device and contactless information storage device
US7879111B2 (en) * 2006-11-02 2011-02-01 Sony Corporation System and method for RFID transfer of MAC, keys
US7971253B1 (en) * 2006-11-21 2011-06-28 Airtight Networks, Inc. Method and system for detecting address rotation and related events in communication networks
US20080186174A1 (en) * 2007-02-02 2008-08-07 Sensormatic Electronics Corporation Item level inventory with a radio frequency identification (RFID) system
US20080231454A1 (en) * 2007-03-23 2008-09-25 Diamond Arrow Communications L.L.C. Cargo Container Monitoring Device
US20080285495A1 (en) * 2007-05-15 2008-11-20 Conexant Systems Inc. Systems and Methods for Communicating to a Disassociated Station in a Protected Network
US20090028329A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US20090028078A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and apparatus for providing security in a radio frequency identification system
US20090028333A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US8204225B2 (en) * 2007-07-23 2012-06-19 Savi Technology, Inc. Method and apparatus for providing security in a radio frequency identification system
US20090028334A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US20110202609A1 (en) * 2010-02-15 2011-08-18 Damaka, Inc. System and method for strategic routing in a peer-to-peer environment
US20110231917A1 (en) * 2010-03-19 2011-09-22 Damaka, Inc. System and method for providing a virtual peer-to-peer environment
US20110238862A1 (en) * 2010-03-29 2011-09-29 Damaka, Inc. System and method for session sweeping between devices
US20110270932A1 (en) * 2010-04-29 2011-11-03 Damaka, Inc. System and method for peer-to-peer media routing using a third party instant messaging system for signaling
US20110291803A1 (en) * 2010-05-27 2011-12-01 Zeljko Bajic Rfid security and mobility architecture
US20110310886A1 (en) * 2010-06-18 2011-12-22 Damaka, Inc. System and method for transferring a call between endpoints in a hybrid peer-to-peer network
US20110317834A1 (en) * 2010-06-23 2011-12-29 Damaka, Inc. System and method for secure messaging in a hybrid peer-to-peer network
US20120054276A1 (en) * 2010-08-25 2012-03-01 Damaka, Inc. System and method for shared session appearance in a hybrid peer-to-peer environment
US20120078609A1 (en) * 2010-09-24 2012-03-29 Damaka, Inc. System and method for language translation in a hybrid peer-to-peer environment
US20120087302A1 (en) * 2010-10-11 2012-04-12 Damaka, Inc. System and method for a reverse invitation in a hybrid peer-to-peer environment

Cited By (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8788665B2 (en) 2000-03-21 2014-07-22 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US9647954B2 (en) 2000-03-21 2017-05-09 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US9077554B1 (en) 2000-03-21 2015-07-07 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
US8547957B2 (en) 2007-07-23 2013-10-01 Savi Technology, Inc. Method and apparatus for providing security in a radio frequency identification system
US20090028078A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and apparatus for providing security in a radio frequency identification system
US8204225B2 (en) 2007-07-23 2012-06-19 Savi Technology, Inc. Method and apparatus for providing security in a radio frequency identification system
US20090028333A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US8116454B2 (en) 2007-07-23 2012-02-14 Savi Technology, Inc. Method and apparatus for providing security in a radio frequency identification system
US20090028329A1 (en) * 2007-07-23 2009-01-29 Savi Technology, Inc. Method and Apparatus for Providing Security in a Radio Frequency Identification System
US8806053B1 (en) 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
US8578450B2 (en) * 2008-06-20 2013-11-05 At&T Intellectual Property Ii, L.P. Methods for distributing information using secure peer-to-peer communications
US20090320102A1 (en) * 2008-06-20 2009-12-24 At&T Corp. Methods for Distributing Information Using Secure Peer-to-Peer Communications
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
US11108815B1 (en) 2009-11-06 2021-08-31 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US10015286B1 (en) * 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
USRE47019E1 (en) 2010-07-14 2018-08-28 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
US20130113611A1 (en) * 2010-08-27 2013-05-09 Korea University Research And Business Foundation Data transmission method in passive communication system
US9136977B2 (en) * 2010-08-27 2015-09-15 Korea University Research And Business Foundation Data transmission method in passive communication system
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
US9554276B2 (en) 2010-10-29 2017-01-24 F5 Networks, Inc. System and method for on the fly protocol conversion in obtaining policy enforcement information
US20120191848A1 (en) * 2011-01-21 2012-07-26 John Peter Norair Method and apparatus for discovering people, products, and/or services via a localized wireless network
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US9985976B1 (en) 2011-12-30 2018-05-29 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
US10097616B2 (en) 2012-04-27 2018-10-09 F5 Networks, Inc. Methods for optimizing service of content requests and devices thereof
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US20150110272A1 (en) * 2013-10-17 2015-04-23 Motorola Solutions, Inc. Methods, systems, and devices to reduce audio truncation during transcoding
US9351157B2 (en) * 2013-10-17 2016-05-24 Motorola Solutions, Inc. Methods, systems, and devices to reduce audio truncation during transcoding
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US20200382305A1 (en) * 2015-12-30 2020-12-03 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
US11838421B2 (en) * 2015-12-30 2023-12-05 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US20220060468A1 (en) * 2016-01-29 2022-02-24 Cable Television Laboratories, Inc. Systems and methods for secure automated network attachment
US11171944B2 (en) * 2016-01-29 2021-11-09 Cable Television Laboratories, Inc. Systems and methods for secure automated network attachment
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
DE102017011588A1 (en) * 2017-12-06 2019-06-06 Giesecke+Devrient Mobile Security Gmbh Secure data transmission of user data
US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
US11924192B2 (en) * 2021-11-08 2024-03-05 Cable Television Laboratories, Inc. Systems and methods for secure automated network attachment

Also Published As

Publication number Publication date
US8116454B2 (en) 2012-02-14
KR20100035712A (en) 2010-04-06
US20090028329A1 (en) 2009-01-29
WO2009015073A2 (en) 2009-01-29
US20150067872A1 (en) 2015-03-05
US20090028078A1 (en) 2009-01-29
WO2009015073A3 (en) 2009-09-03
US20090028334A1 (en) 2009-01-29
US8204225B2 (en) 2012-06-19
EP2181536A2 (en) 2010-05-05
CN101803334A (en) 2010-08-11
US8547957B2 (en) 2013-10-01
US20090028333A1 (en) 2009-01-29

Similar Documents

Publication Publication Date Title
US8547957B2 (en) Method and apparatus for providing security in a radio frequency identification system
CN100580610C (en) Security link management method in dynamic networks
US8745717B2 (en) Management of multiple connections to a security token access device
US6546492B1 (en) System for secure controlled electronic memory updates via networks
US9867042B2 (en) Radio frequency identification technology incorporating cryptographics
EP1430640B1 (en) A method for authenticating a user in a terminal, an authentication system, a terminal, and an authorization device
US20070023508A1 (en) Proximity validation system and method
EP1881664B1 (en) Automatic management of security information for a security token access device with multiple connections
US20100201489A1 (en) System, method and program product for communicating a privacy policy associated with a radio frequency identification tag and associated object
US20100146273A1 (en) Method for passive rfid security according to security mode
JP4803145B2 (en) Key sharing method and key distribution system
US10615974B2 (en) Security authentication system for generating secure key by combining multi-user authentication elements and security authentication method therefor
EP1881663B1 (en) Management of multiple connections to a security token access device
CN101707522B (en) Method and system for authentication and connection
WO2011027191A1 (en) A method, system, and computer readable medium for controlling access to a memory in a memory device
CN114450990A (en) Multi-factor authentication for providing credentials for secure messages via contactless cards
CN103404076B (en) On the 3rd entity, authenticate the method for the first and second entities
US10615975B2 (en) Security authentication method for generating secure key by combining authentication elements of multi-users
KR20220100886A (en) A method for authenticating users on a network slice
US20070287455A1 (en) Method of registering a network, and mobile station and communication system using the same
KR101210605B1 (en) Method for passive RFID security according to security mode
EP1881433B1 (en) Method and apparatus for the management of multiple connections to a security token access device

Legal Events

Date Code Title Description
AS Assignment

Owner name: SAVI TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BALABINE, IGOR V.;CARGONJA, NIKOLA;EVANS, ALLAN M.;AND OTHERS;REEL/FRAME:020745/0062;SIGNING DATES FROM 20080324 TO 20080331

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION