System and method for data protection using dynamic tokens

A Data Protection Server (DPS) configured to authenticate, encrypt and decrypt blocks of data by using dynamic tokens. Instances of a DPS may be deployed in association with a host server and with multiple client devices to protect data exchanged between them. Since each DPS instance typically requires minimal device storage and computational resources, use of a DPS may be particularly advantageous in connection with the protection of data generated by limited resources devices.

FIELD

The present disclosure pertains generally to data authentication, encryption and decryption methods for enhancing the security of computer systems and communications and, in particular, to data protection techniques useful in devices with limited computing and other resources.

BACKGROUND

Maintaining the security of data communicated over, for example, wide or local area networks is typically of great importance to the operators or users of such networks. Data security may be enhanced within such networks and related computing systems through the use of authentication, encryption and decryption techniques.

However, conventional approaches to data encryption and decryption yielding a high level of data security may consume large amounts of one or both of computing and memory resources. As a consequence, such approaches may be infeasible in data security applications involving devices having only limited computational or data storage capabilities. For example, many proposed Internet of Things (“IoT”) devices have very limited storage, computing resources and available power. Moreover, it will be important to be able to produce various IoT devices inexpensively so as not to unduly limit the growth of new markets relying upon such devices. Accordingly, any security enhancements to such devices should be capable of being implemented with minimal effort and at low cost.

Finally, many existing methods of data encryption rely upon the same “key” to encrypt data and to later decrypt the encrypted data. If the same key is repeatedly used for encryption and decryption, an observer may be able to determine the key and decrypt the observed data. Thus, in many applications it would be advantageous to avoid repetitive use of the same encryption key.

SUMMARY

In one aspect the disclosure pertains to a Data Protection Server (DPS) configured to authenticate, encrypt and decrypt blocks of data by using dynamic tokens. Instances of a DPS may be deployed in association with a host server and with multiple client devices to protect data exchanged between them. Embodiments of the DPS are particularly useful for limited resource devices such as wireless sensors. This is because each DPS instance typically requires minimal device storage and computational resources, and utilizes a simple service access protocol.

A client device may be a wireless sensor with access to a local or remote DPS instance. Once a client device is deployed and used it can access a DPS to exchange protected data with the host server.

An instance of a DPS is configured to provide encryption and decryption services for data sent by a particular client device by synthesizing and using Dynamic Key Instances (DKIs). In general, a unique Dynamic Key Instance (DKI) will be created by the DPS instance for each data packet communicated by the client device. A given DKI may be generated using a Dynamic Data Token (DDT) provided by the client device and Key Creation Material (KCM) associated with the client device. The KCM associated with a particular client device is generally saved in a Device Data Base (DDB) in association with a Device Serial Number (DSN) or other identifying information associated with the client device. By accessing the DDB, the host server is able to obtain the KCM necessary to decrypt data packets received from a given device associated with a particular DSN.

In one aspect the disclosure relates to a computer-implemented method for data protection. The method includes determining that a dynamic data token (DDT) has been received, the DDT including a plurality of DDT elements. The method includes generating a dynamic key instance (DKI) using the DDT and key creation material (KCM) including a plurality of KCM elements. The DKI includes an ordered combination of integer values corresponding to KCM elements included within the plurality of KCM elements. Data is then encrypted using the DKI so as to create encrypted data. A data packet including the encrypted data is then sent.

The DKI may be generated by selecting, for each of the plurality of DDT elements, at least one of the plurality of KCM elements addressed by a value of the one of the plurality of DDT elements. The KCM may be associated with a device serial number (DSN) of a device, and the method may include storing the KCM within a non-volatile memory of the device.

In another aspect the disclosure relates to an electronic device arrangement including a processor, a wireless transceiver, an electronic device configured to produce data and a memory including program code for a data protection server. When executed, the code for the data causes the processor to determine that a dynamic data token (DDT) has been received by the wireless device, the DDT including a plurality of DDT elements. The code further causes the processor to generate a dynamic key instance (DKI) using the DDT and key creation material (KCM) including a plurality of KCM elements. The DKI includes an ordered combination of integer values corresponding to KCM elements included within the plurality of KCM elements. Execution of the code further causes the processor to receive the data from the electronic device and to encrypt, using the DKI, the data so as to create encrypted data. The processor is further configured by the program code to instruct the wireless transceiver to send a data packet containing the encrypted data.

The disclosed system and method for data protection includes a number of advantageous features. For example, the disclosed approach results in an orders of magnitude reduction in the amount of storage required to support multiple keys, with only lightweight logic needed to provide such keys. The disclosed data protection schemes can be additive to existing security methods and are capable of being used whenever encryption keys are used. Moreover, the low overhead of the disclosed data protection approaches should assure compatibility with existing and future data communication protocols.

In terms of applicability to existing technologies, the disclosed data protection approaches are immediately useful for low power wireless protocols such as WiFi, Bluetooth, Thread, and the like. In addition, the disclosed data protection scheme may be useful for periodic authentication. Finally, the disclosed DPS encryption methodology may obviate the need to exchange keys, such as is required by various conventional encryption approaches (e.g., Diffie Hellman encryption).

DETAILED DESCRIPTION

The following acronyms are utilized within the disclosure:

AES—Advanced Encryption Standard

BLE—Bluetooth Low Energy Standard

DDT—Dynamic Data Token

DKI—Dynamic Key Instance

DPS—Data Protection Server

DSN—Device Serial Number

KCM—Key Creation Material

JTAG—Joint Test Action Group

Attention is now directed toFIG. 1, which illustratively represents a system100incorporating a host server102and a plurality of devices104configured for data protection in accordance with the disclosure. As shown, the host server102includes a data protection server (DPS)108, an application110and a device database (DDB)112. Each device104also includes a data protection server114. In one embodiment each device104includes a wireless transceiver116and, for example, a sensor configured to produce sensor data. The data protection servers108,114each comprise an entity implemented in hardware, firmware, software or any combination thereof that provides the authentication, encryption and decryption services described hereinafter. In one embodiment, the DPS114within each device104protects data sent by each device104to the host server102over a network120. Such data may be sent by the devices104at the request of, for example, the application110or in order to support operation of the application110.

In the embodiment ofFIG. 1each wireless transceiver116may comprise, for example, a cellular modem or other wide area network transceiver capable of establishing a connection with the host server102via the network120. In such embodiments the network120may collectively include one or more wide area networks, a cellular network, and/or the Internet. As is discussed below, in other embodiments the plurality of devices may each include a low-power transceiver designed to communicate with a nearby access point or other wireless node capable of establishing a network connection with a remote host server

FIG. 2illustrates a process200for generating cyphertext204from cleartext208using a DPS in accordance with the disclosure. In typical operation of the system100, the DPS108of the host server102creates and sends a dynamic data token (DDT) to one of the devices104(stage224). Upon determining a DDT has been received, the DPS114of the device104generates a dynamic key instance (DKI) using the DDT and key creation material (KCM)210stored in the device104(stage220). Each DKI comprises an orderly collection of elements used as an encryption or decryption key. Any data to be sent by the device104is encrypted by the DPS114using the DKI so as to create encrypted data (stage228). The encryption of the cleartext208using the DKI may be performed using conventional encryption schemes such as, for example, the Advanced Encryption Standard (AES) algorithm. The encrypted data204is then sent to the host server102via the wireless transceiver116and interface226. The host server102relies upon a corresponding DKI created by the DPS108to decrypt the encrypted data.

In one embodiment each DPS may be implemented in hardware using a single integrated circuit including a SPI interface. In this embodiment the only inputs to the IC are DDT and Cleartext and the only output from the IC is Cyphertext. The IC may further include local memory for storing KCM, an AES engine, logic to create DKIs and SPI circuitry.

As is discussed below, the encryption methodologies employed by each DPS require only minimal storage, are computationally efficient and utilize a simple service access protocol. As a consequence, the disclosed encryption techniques are useful for devices having only limited resource such as, for example, wireless sensors and other devices utilized in Internet of Things (IoT) applications.

In one embodiment the device database112includes a collection of KCM stored as a function of the serial number or other identifying information of a device104. In the case in which each device104is uniquely identifiable by a device serial number (DSN), the DDB112includes a stored collection of DSN[n] and KCM[n] pairs. In some embodiments the DDB112may comprise a global DDB containing DSN[n] and KCM[n] pairs for all devices104within the system100. In other embodiments the DDB112may be one of a number of other DDBs containing subsets of DSN[n] and KCM[n] pairs. In a typical implementation, a DSN will usually be assigned by a device vendor during manufacturing of the devices104and stored within the DDB112in association with the KCM respectively associated with the DSN information.

Attention is now directed toFIG. 3, which illustratively represents a process300of creating a DKI330. Referring toFIG. 3, a DDT310is comprised of T+1 elements, ordered from TE[0] (3400) to TE[T] (340T), where each element TE[n] (340) ranges in integer values from 0 to M. As is explained below, the collection of elements TE[n] (340) of the DDT310are used with a KCM320in the creation of the DKI330. The DDT310may be mathematically represented as:
DDT={TE[0],TE[1] , , , TE[T]}
0<=TE[n]<=M
0<=n<=T
In an exemplary embodiment each element TE[n] (340) of the DDT310is independent from the other. As a consequence, some elements TE[n] (340) may have identical values.

Again referring toFIG. 3, the KCM320is comprised of M+1 elements, ordered from ME[0] (3500) to ME[M] (350M), where each element ME[n] ranges in integer values from 0 to KE_MAX. Each element ME[n] is stored and addressable and used with a DDT in the creation of a DKI. The DDT310may be mathematically represented as:
KCM={ME[0],ME[1] , , , ME[M]}
0<=ME[n]<=KE_MAX
0<=n<=M
In an exemplary embodiment each element ME[n] (350) of the DDT310is independent from the other. As a consequence, some elements ME[n] (350) may have identical values.

As shown inFIG. 3, the DKI330may include T+1 elements, ordered from KE[0] to KE[T], where each element ranges in integer values from 0 to KE_MAX. In general, the number of elements of the DKI330will equal the number of elements included within the DDT310. The DKI330may be mathematically represented as follows:
DKI={KE[0],KE[1] , , , KE[T]}
0<=KE[n]<=KE_MAX
0<=n<=T

The process300for creating a unique, single DKI330includes receiving a specific DDT310at a device104. Once the DDT310has been received, the value of the first element TE[0] (3400) of the DDT310determines which element ME[n] of the KCM320associated with the device104is first read and accessed. In the example ofFIG. 3the value of TE[0] (3400) is assumed to be 1, which results in the value of KCM element addressed by this value, i.e., ME[1] (3501), being assigned to the first element KE[0] (3600) of the DKI330. Similarly, the value of the second element of DDT (TE[1] (3401of DDT310) is used to read the value of the KCM element (ME[x] of KCM320) addressed by this value. This KCM element value is assigned to the second element of the DKI (KE[1] (3601) of DKI330). The same procedure repeats for the next element until the last element (TE[T] of DDT310) is processed. The resulting DKI330has the same number of elements as the DDT, with the value of each such element being collected from the KCM320.

Attention is now directed toFIG. 4, which depicts a process400for manufacturing and transferring KCM to individual devices404such as, for example, sensor devices. In one embodiment a single KCM[x]412is stored in a non-volatile memory of a single device404via a JTAG interface424of a manufacturing jig420. The same KCM[x]412is also stored, under the control of an application430, in a DDB440of a manufacturing server402. This may be done during manufacturing of multiple devices404where each device404may have the same or different KCM412. In this embodiment, a most-likely-unique KCM412is generated in the manner described below and stored for each device404. The DDB440stores all pairs of KCMs412and DSNs408for all manufactured devices.

In one embodiment, a procedure to generate a most-likely-unique KCM may be employed. This procedure may involve storing, into each of 64 (M=63) non-volatile memory elements of the manufacturing server402, a random integer ranging from 0 to 255 (KE_MAX=255). The size of each such element is generally one byte, i.e., one octet or 8 bits. Accordingly, the total space required for this form of a KCM is 64 bytes. The odds of having two such 64 bytes KCMs with identical values are very low.

In one embodiment, each DDT may be synthesized by using a random number generator to create 16 TE[n] elements (T=15) with values ranging from 0 to 63 (M=63). The ordered collection of these elements comprises single DDT. The odds of picking the same DDT using this procedure are also very low; specifically, the odds are calculated to be one out of 16!, which is equivalent to one out of 2.092279e+13.

Turning now toFIG. 5, there is illustrated a sensor system500including a plurality of sensor devices504configured in accordance with an embodiment. As shown, the sensors504are in wireless communication over Bluetooth Low Energy (BLE) connections with a BLE host524instantiated at an aggregation point520. In one embodiment the BLE host524communicates with a local “cloud” comprised of a local application530executing on a server component502in communication with, or containing, a DDB540. Each sensor504generally has a single KCM stored in flash memory and a unique DSN. The DDB540also stores the KCM and unique DSN associated with each sensor504. The aggregation point520/BLE host524may be configured to appear to the sensor devices504as a “BLE Host”. In this embodiment each sensor device504is connected as a “BLE Peripheral” over one of multiple BLE connections.

In one embodiment each sensor device may include, for example, a Nordic Semiconductor PCA10001 V2.2.0 board as configured as a BLE version 4.0 Peripheral. Similarly, the aggregation point520/BLE host524may be implemented using a Nordic Semiconductor PCA10000 V2.2.0 USB board configured as a BLE version 4.0 Host. The local server502may be implemented using a conventional computing device such as, for example, a personal computer (PC) configured with Microsoft Windows 7 or other commercially available operating system. In one embodiment the BLE host524may establish with each sensor504(based on its DSN[n]) a standard BLE version 4.0 (or later version) Host to Peripheral connection.

During operation of the system500, the BLE host524is configured to authenticate each of a set of n sensor devices504. The process of authenticating a sensor device504having a specific DSN508is initiated when the BLE host524sends data encrypted in the manner described below (“e-Data[n]”) to the device504. The received e-Data[n] is decrypted, yielding unencrypted data (“Data[n]”). This unencrypted data is manipulated in the manner discussed below to produce manipulated data (“m-Data[n]”). The manipulated data is then encrypted so as to provide encrypted, manipulated data (“e-m-Data[n]”), which is sent to the host for verification.

As part of this authentication process, the BLE host524generates a set of [n] DDTs. In one embodiment each such DDT is different from the other DDTs in this set and completely addresses the entire KCM storage area. Moreover, certain KCM locations may be addressed multiple times. These [n] DDTs are then used by the BLE host524to generate a corresponding set of [n] challenge data blocks, i.e., the e-Data[n] elements. Each challenge data block is different from the other data blocks in this set.

Considering now the details of an exemplary authentication process, the following authentication protocol may be executed between the BLE Host524and each sensor504being authenticated:1—BLE Host524sends, encrypted with DDT[1], e-Data[1] and DDT[1] to sensor504.2—Sensor504decrypts e-Data[1], using DDT[1], into Data[1].3—Sensor504manipulates Data[1] in a pre-determined way:3A—Each Data[1] byte is reversed into m-Data[1].4—Sensor504sends, encrypted with DDT[1], e-m-Data[1] to BLE Host524.5—BLE Host524decrypts e-m-Data[1], with DDT[1], into m-Data[1].6—BLE Host524verifies that m-Data[1] corresponds to Data[1].7—Above steps repeat for the rest of the set.8—Authentication of sensor504verified if all m-Data blocks correspond to original Data blocks.

Referring now toFIG. 6, there is illustrated an exemplary message sequence600between the BLE host524and one of the participating sensors504. As shown, the BLE Host524sends a DDT[n] to the sensor504with DSN[n], where n corresponds to the one of the participating sensors504(stage604). In the case of the first DDT[n] which is sent (i.e., DDT[1]) by the BLE host524to the participating sensor504, the sensor504uses that DDT[1] to generate DKI[1] using KCM[n] (stage608). The sensor504in turn and uses DKI[1] to encrypt the 1stpacket of data to be sent to the BLE host524by the sensor504(stage612). In one embodiment DKI[1] is used as the key for 128-AES encryption performed during stage612. The sensor504then transmits the encrypted data packet to the BLE host524(stage616). Upon receiving this encrypted packet, the BLE Host524uses DDT[1] to generate DKI[1] (stage620). The resulting DKI[1] is then in turn used to decrypt the 1stpacket of data (stage624). In one embodiment DKI[1] is used by the BLE host524as a key for 128-AES decryption during stage624. Stages604though624are then repeated with respect to each new DDT[n] until the sensor504has completed transmitting all data desired to be conveyed to the BLE host524.

Turning now toFIG. 7, a flowchart is provided of an exemplary encryption process700carried out by a device configured with a DPS. In the example ofFIG. 7the device is in communication with another entity capable of sending one or more DDTs to the device and receiving one or more correspondingly encrypted data packets from the device. When the device has data to send to the other entity (stage704), it checks to determine if it has received a DDT from the host and waits for a DDT if none have yet been received (stage706). Once a valid DDT has been received and the device has data to send to the host, the device DPS generates a DKI from the received DDT and the KCM associated with the device (stage710). The DPS then encrypts the data using the DKI (stage714) and presents it to the device. The device then sends the resulting encrypted data packet upstream to the other entity (stage720).

Attention is now directed toFIG. 8, which illustratively represents a system800incorporating a host server802, an access point830, and a plurality of devices850configured for data protection in accordance with the disclosure. In one embodiment each device850includes a wireless transceiver and, for example, a sensor configured to produce sensor data. As is discussed below, the embodiment ofFIG. 8is particularly useful in applications involving, for example, the Internet of Things (IoT) and other applications in which an economical and secure deployment is desired.

As shown, the host server802includes a DPS814, an application810and a DDB812. Each device850also includes a data protection server860. During operation, each device850receives DDTs from a DPS840of the access point830and uses its local DPS860to generate secure data in the manner discussed above. That secure data is then transferred to the access point830, at which it is decrypted by the DPS840. In like manner the access point830receives DDTs from the DPS814associated with the application810. This enables the DPS840of the access point830to encrypt and transfer the data received from the devices850to the DPS814through a network represented as cloud820. Application810may use DPS814to authenticate the access point830and the devices850in the manner described herein. The DPS814also decrypts the encrypted data received from the access point DPS840.

The system800is designed to support a number of specific use cases. For example, the system800may form part of a home security system in which the devices850comprise security devices connected to access point830via Bluetooth protocols. In this case the devices850may include sensors and actuators such as, for example, door locks, occupancy detectors, fire and smoke detectors, glass shutter sensors, temperature and humidity sensors and so on. In one home security implementation the access point830continuously communicates with the devices850via Bluetooth using the secure DPS protocol described herein. The access point830may be connected to the “cloud”820via on-board cellular modem. The connectivity to the “cloud”820can be done in many other ways: [1] WiFi to local router, [2] Ethernet to Cable Modem local port, [3] Thread protocol to Thread Master and more. In this embodiment the host server802may be in the form of, for example, a “home security service center” where monitoring for alerts and the like takes place based upon the data securely received from the devices850.

In another use case the system800may form part of a payment system in which the devices850comprise “smart” plastic cards and the access point830comprises a point of sale (POS) terminal. Each device850, i.e., “smart” plastic card, includes on-board DPS860in communication with the DPS840of the access point830, i.e., the POS. It is noted that replicating a “smart” plastic payment card having an on-board DPS is believed to be orders of magnitude more difficult than replicating smart cards secured using conventional means. Essentially any smart or other payment card capable of including a DPS may be protected. Moreover, all types of communication with a POS utilized by such cards (e.g., magnetic strip, Near Field Communication (NFC) and Bluetooth) may also be protected using the disclosed DPS security protocol.

The system800may also be utilized in connection with the management of retail beacons. In this embodiment a large retailer may employ numerous inexpensive, low power communicating devices850throughout the store floor. These devices850communicate with an Access Point830that is part of the local management system and configured with a DPS840. These devices850may display items prices and managed by the store. The authenticity of these devices850is verified via on-board DPS860in order to prevent, for example, a situation where the retailer may purchase additional devices made by an unlicensed vendor.

In yet another use case the system800may be utilized in transportation and product distribution applications such as, for example, in connection with the continuous authentication of high value containers. Such containers may include high value medication or other high value goods stored in secure containers for distribution. The identity of a container is supported by active RFID devices with DPS on-board. The authenticity of these containers is maintained throughout the distribution chain with the use of DPS. The low overhead and correspondingly low power consumption of the disclosed DPS security protocol is believed to be particularly advantageous in applications involving active RFID devices, which tend to have limited power capabilities (e.g., power may be provided by small batteries or energy harvesting).

Attention is now directed toFIG. 9, which illustrates an alternative process900for generating cyphertext934from cleartext930using a DPS902in accordance with the disclosure. The alternative process900is similar to the process200, but includes additional complexity to enhance data protection. In one embodiment the DPS902may include a packet assembly module916, a random number generator918, increment only counters (not shown) and other security enhancement circuitry and methods. In cases in which, for example, the cleartext930is sensor data or other data that does not typically change from packet to packet, a potential security vulnerability is created. This may be alleviated by using the packet assembly module916to create new packets including the cleartext930and random data from the random number generator918.

As shown inFIG. 9, a dynamic data token (DDT) sent by an entity is received by a device including a DPS902(stage924). Upon determining a DDT has been received, the DPS902generates a dynamic key instance (DKI) using the DDT and key creation material (KCM)910stored by the DPS902of the device104(stage920). Each DKI comprises an orderly collection of elements used as an encryption or decryption key. Any data to be sent by the device is encrypted, using the DKI, so as to create encrypted data (stage928). The encryption of the cleartext930using the DKI may be performed using conventional encryption schemes such as, for example, the Advanced Encryption Standard (AES) algorithm. The encrypted data204is then sent to the host server102via an interface226, which relies upon a corresponding DKI created by the DPS108to decrypt the encrypted data. In one embodiment the device may include extra storage and firmware in order to protect from attacks using repeat DDTs intended to, for example, discover the KCM.

FIG. 10illustrates an exemplary sensor device1002configured to implement the DPS security protocol in accordance with an embodiment. The device1002includes standard components such as a processor1010connected to input/output devices1012via a bus1014. The processor1010can be a general purpose processor, a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), and/or the like. The input/output devices1012may include a sensor1037, General Purpose IO (GPIO) (not shown) and the like. A network interface circuit1016is also connected to the bus1014to provide connectivity to a network1017. A memory1020is also connected to the bus1014. The memory1020includes sensor data1022collected by the sensor1037and instructions executed by the processor1010. In particular, a DPS module1024is stored in memory1020. The DPS module1024includes instructions to implement the DPS security protocol disclosed herein. Alternately, the operations disclosed herein may be distributed across a number of machines of the type shown inFIG. 10.

The memory1020can be, for example, any type of non-volatile memory device, a random access memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), a read-only memory (ROM) and/or so forth. It is understood that although a single memory1020is illustrated, the memory1020may comprise one or more separate memory devices. For example, in order to enhance security the DPS module1024could be instantiated in a physically separate and secure memory. Alternatively, the DPS module1024could comprise a separate integrated circuit including dedicated processing and memory resources. Alternatively, the DPS module1024can be part of an integrated secure zone of a security process IC.

Referring now toFIG. 11, there is illustrated an exemplary host server1102configured to implement the DPS security protocol in accordance with an embodiment. The server1102includes standard components such as a processor1110, a LAN interface1112and a network interface circuit1116mutually connected via a bus1114. The LAN interface1112enables the host server1102to communicate with a DDB1134and the network interface circuit1116provides connectivity to a network1117. A memory1120is also connected to the bus1114. The memory1120includes instructions executed by the processor1110including an application module1122and a DPS module1124. During operation, the processor executes the DPS module1124when requested by the application module1122. The DPS module1124produces decrypted sensor data1126in response to encrypted sensor data received via the network interface circuit1116from one or more sensor devices. Again, the DPS module1124could be located in physically separate and secure memory or, alternatively, could be implemented using a dedicated integrated circuit.

It should be noted that although the exemplary embodiments tend to describe a unidirectional flow of DPS-protected data (i.e., from a “host” to a “client”), the roles of “host” and “client” are interchangeable with respect to pairs of devices in communication. That is, a given device may function as a client at certain times (and encrypt data using a DPS) and that same device may function some of the time as a host (and decrypt data using a DPS). Although in the case of a sensor device functioning as a DPS client the sensor device may collect data, encrypt it, and send it to the host, in many instances the host is required to manage the sensor. Accordingly, when sending instructions to a sensor device a host may function as a DPS client and DPS-encrypt such instructions before sending them to the client device. Moreover, a sensor device will typically act to authenticate a host (in essentially the same manner as the host authenticates the sensor device) before acting on management directives from a host.

Such mutual authentication may be even more important in other applications such as, for example, those involving payment cards and POS terminals. In such embodiments a fully-featured DPS supporting both client and host roles may be instantiated on both the payment card and the POS terminal.

Referring now toFIG. 12, a flowchart is provided of a process1200for mutual DPS authentication in accordance with the disclosure. As shown, the process begins when a host entity uses its own DPS to authenticate a client entity in the manner described above with reference toFIG. 5(stage1204). The host entity then sends a request for data to the client entity (stage1208). In response to the request, the client uses its own DPS to authenticate the host in the manner described above with reference toFIG. 5(stage1212). Once the host has been successfully authenticated the client sends the requested data to the host (stage1216).

As used in this specification, a module can be, for example, any assembly and/or set of operatively-coupled electrical components associated with performing a specific function(s), and can include, for example, a memory, a processor, electrical traces, optical connectors, software (that is stored in memory and/or executing in hardware) and/or the like.

As used in this specification, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, the term “an actuator” is intended to mean a single actuator or a combination of actuators.

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the invention, which is done to aid in understanding the features and functionality that can be included in the invention. The invention is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, although the invention is described above in terms of various embodiments and implementations, it should be understood that the various features and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in some combination, to one or more of the other embodiments of the invention, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus the breadth and scope of the present invention should not be limited by any of the above-described embodiments.

Some embodiments described herein relate to a computer storage product with a non-transitory computer-readable medium (also can be referred to as a non-transitory processor-readable medium) having instructions or computer code thereon for performing various computer-implemented operations. The computer-readable medium (or processor-readable medium) is non-transitory in the sense that it does not include transitory propagating signals per se (e.g., a propagating electromagnetic wave carrying information on a transmission medium such as space or a cable). The media and computer code (also can be referred to as code) may be those designed and constructed for the specific purpose or purposes. Examples of non-transitory computer-readable media in which the KCM may reside include, without limitation, one time programmable (OTP) memory, protected Random-Access Memory (RAM) and flash memory.

Examples of computer code include, but are not limited to, micro-code or micro-instructions, machine instructions, such as produced by a compiler, code used to produce a web service, and files containing higher-level instructions that are executed by a computer using an interpreter. For example, embodiments may be implemented using imperative programming languages (e.g., C, Fortran, etc.), functional programming languages (Haskell, Erlang, etc.), logical programming languages (e.g., Prolog), object-oriented programming languages (e.g., Java, C++, etc.) or other suitable programming languages and/or development tools. Additional examples of computer code include, but are not limited to, control signals, encrypted code, and compressed code.

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Where methods described above indicate certain events occurring in certain order, the ordering of certain events may be modified. Additionally, certain of the events may be performed concurrently in a parallel process when possible, as well as performed sequentially as described above. Although various modules in the different devices are shown to be located in the processors of the device, they can also be located/stored in the memory of the device (e.g., software modules) and can be accessed and executed by the processors. Accordingly, the specification is intended to embrace all such modifications and variations of the disclosed embodiments that fall within the spirit and scope of the appended claims.