SYSTEM AND METHOD FOR DATA PROTECTION USING DYNAMIC TOKENS

Abstract

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.

Claims

1. A server arrangement, comprising: a processor; a device database storing a device serial number (DSN) and key creation material (KCM) pair for each of a plurality of electronic devices; a memory including program code for a data protection server which, when executed, causes the processor to: send, to one of the plurality electronic devices, a dynamic data token (DDT); receive encrypted data generated by the one of the plurality of electronic devices using a dynamic key instance (DKI), the DKI including a plurality of values of KCM elements selected from the KCM for the one of the plurality of electronic devices based at least in part upon the DDT; and decrypt the encrypted data using the DDT and the KCM for the one of the plurality of electronic devices.

2. The server arrangement of claim 1 wherein the DDT includes a plurality DDT elements and wherein values of the DDT elements address ones of the KCM elements selected from the KCM associated with the one of the plurality of electronic devices.

3. The server arrangement of claim 1 wherein the program code further includes code for causing the processor to execute a portion of an authentication protocol, the authentication protocol including: (1) encrypting data (Data[i]) using a dynamic data token (DDT[i]), thereby generating encrypted data (e-Data[i]); (2) sending, to one of the plurality of electronic devices, the e-Data[i] and the DDT[i]; (3) receiving, from the one of the plurality of electronic devices, a manipulated and encrypted version of Data[i] (e-m-Data[i]); (4) decrypting the e-m-Data[i] using DDT[i], thereby generating manipulated data (m-Data[i]); (5) verifying that the m-Data[i] corresponds to a manipulated version of Data[i]; (6) repeating operations (1) through (5) for i=1 to m, where m is greater than one; wherein the one of the plurality of electronic devices is authenticated upon verifying that the m-Data[i] corresponds to the manipulated version of Data[i] for each of i=1 to m.

4. An access point, comprising: a processor; a transceiver configured for communication with a plurality of electronic devices wherein a device serial number (DSN) and key creation material (KCM) pair is associated with each of the plurality of electronic devices; a memory including program code for a data protection server which, when executed, causes the processor to: instruct the transceiver to send, to one of the plurality electronic devices, a dynamic data token (DDT); receive encrypted data from one of the plurality of electronic devices, the encrypted data being generated by encrypting input data based upon the DDT and the KCM for the one of the plurality of electronic devices; and decrypt the encrypted data using the DDT and the KCM for the one of the plurality of electronic devices.

5. The access point of claim 4 wherein the encrypted data is generated using a dynamic key instance (DKI), the DKI including a plurality of values of KCM elements selected from the KCM for the one of the plurality of electronic devices based at least in part upon the DDT.

6. The access point of claim 4 further including a network interface facilitating communication with a server wherein the server executes a first additional data protection server using additional key creation material associated with the server and the plurality of electronic devices execute further additional data protection servers using the KCM associated with each of the plurality of electronic devices.

7. The access point of claim 4 wherein the program code further includes code for causing the processor to execute a portion of an authentication protocol, the authentication protocol including: (1) encrypting data (Data[i]) using a dynamic data token (DDT[i]), thereby generating encrypted data (e-Data[i]); (2) sending, to one of the plurality of electronic devices, the e-Data[i] and the DDT[i]; (3) receiving, from the one of the plurality of electronic devices, a manipulated and encrypted version of Data[i] (e-m-Data[i]); (4) decrypting the e-m-Data[i]) using the DDT[i], thereby generating manipulated data (m-Data[i]); (5) verifying that the m-Data[i] corresponds to a manipulated version of Data[i]; (6) repeating operations (1) through (5) for i=1 to m, where m is greater than one; (7) determining the one of the plurality of electronic devices to be authenticated upon verifying that the m-Data[i] corresponds to the manipulated version of Data[i] for each of i=1 to m.

8. A computer-implemented method for data protection, the method comprising: generating and storing, at an aggregation point in communication with a plurality of sensors, a dynamic data token (DDT) wherein the DDT includes a plurality of DDT elements and wherein key creation material (KCM) is associated with each of the plurality of sensors; sending the DDT to one of the plurality of sensors; receiving encrypted data generated by the one of the plurality of sensors using a dynamic key instance (DKI), the DKI including a plurality of values of KCM elements selected from the KCM for the one of the plurality of electronic devices based at least in part upon the DDT; and decrypting the encrypted data using the DDT and the KCM for the one of the plurality of electronic devices.

9. A method for authenticating an electronic device, the method comprising: (1) encrypting Data[i] using DDT[i], thereby generating encrypted data (e-Data[i]); (2) sending, to one of the plurality of electronic devices, e-Data[i] and DDT[i]; (3) receiving, from the one of the plurality of electronic devices, a manipulated and encrypted version of Data[i] (e-m-Data[i]); (4) decrypting the e-m-Data[i]) using DDT[i], thereby generating m-Data[i]; (5) verifying that m-Data[i] corresponds to a manipulated version of Data[i]; (6) repeating operations (1) through (5) for i=1 to m, where m is greater than one; (7) determining the one of the plurality of electronic devices to be authenticated upon verifying that m-Data[i] corresponds to a manipulated version of Data[i] for each of i=1 to m.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The skilled artisan will understand that the drawings primarily are for illustrative purposes and are not intended to limit the scope of the inventive subject matter described herein. The drawings are not necessarily to scale; in some instances, various aspects of the inventive subject matter disclosed herein may be shown exaggerated or enlarged in the drawings to facilitate an understanding of different features. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. In the drawings, like reference characters generally refer to like features (e.g., functionally similar and/or structurally similar elements).

[0025] FIG. 1 illustratively represents a system incorporating a host server and a plurality of devices configured for data protection in accordance with the disclosure.

[0026] FIG. 2 illustrates a process for generating cyphertext from cleartext using a data protection server in accordance with the disclosure.

[0027] FIG. 3 illustratively represents a process of creating a dynamic key instance.

[0028] FIG. 4 depicts a process for manufacturing and transferring key creation material to individual devices, such as sensor devices.

[0029] FIG. 5 illustrates a sensor system including a plurality of sensor devices configured in accordance with an embodiment.

[0030] FIG. 6 illustrates an exemplary message sequence between a BLE host and one of a set of sensors.

[0031] FIG. 7 is a flowchart of an exemplary encryption process carried out by a device configured with a data protection server.

[0032] FIG. 8 illustratively represents a system incorporating a host server, an access point, and a plurality of devices configured for data protection in accordance with the disclosure.

[0033] FIG. 9 illustrates an alternative process for generating cyphertext from cleartext using a data protection server in accordance with the disclosure.

[0034] FIG. 10 is a block diagram of an exemplary sensor device configured to implement a security protocol in accordance with an embodiment.

[0035] FIG. 11 is a block diagram of an exemplary host server configured to implement a security protocol in accordance with an embodiment.

[0036] FIG. 12 is a flowchart of a process for mutual DPS authentication in accordance with the disclosure.

DETAILED DESCRIPTION

[0037] The following acronyms are utilized within the disclosure:

[0038] AES—Advanced Encryption Standard

[0039] BLE—Bluetooth Low Energy Standard

[0040] DDB—Device Data Base (see Definitions section)

[0041] DDT—Dynamic Data Token

[0042] DKI—Dynamic Key Instance

[0043] DPS—Data Protection Server

[0044] DSN—Device Serial Number

[0045] KCM—Key Creation Material

[0046] JTAG—Joint Test Action Group

[0047] Attention is now directed to FIG. 1, which illustratively represents a system 100 incorporating a host server 102 and a plurality of devices 104 configured for data protection in accordance with the disclosure. As shown, the host server 102 includes a data protection server (DPS) 108, an application 110 and a device database (DDB) 112. Each device 104 also includes a data protection server 114. In one embodiment each device 104 includes a wireless transceiver 116 and, for example, a sensor configured to produce sensor data. The data protection servers 108, 114 each 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 DPS 114 within each device 104 protects data sent by each device 104 to the host server 102 over a network 120. Such data may be sent by the devices 104 at the request of, for example, the application 110 or in order to support operation of the application 110.

[0048] In the embodiment of FIG. 1 each wireless transceiver 116 may comprise, for example, a cellular modem or other wide area network transceiver capable of establishing a connection with the host server 102 via the network 120. In such embodiments the network 120 may 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.

[0049] FIG. 2 illustrates a process 200 for generating cyphertext 204 from cleartext 208 using a DPS in accordance with the disclosure. In typical operation of the system 100, the DPS 108 of the host server 102 creates and sends a dynamic data token (DDT) to one of the devices 104 (stage 224). Upon determining a DDT has been received, the DPS 114 of the device 104 generates a dynamic key instance (DKI) using the DDT and key creation material (KCM) 210 stored in the device 104 (stage 220). Each DKI comprises an orderly collection of elements used as an encryption or decryption key. Any data to be sent by the device 104 is encrypted by the DPS 114 using the DKI so as to create encrypted data (stage 228). The encryption of the cleartext 208 using the DKI may be performed using conventional encryption schemes such as, for example, the Advanced Encryption Standard (AES) algorithm. The encrypted data 204 is then sent to the host server 102 via the wireless transceiver 116 and interface 226. The host server 102 relies upon a corresponding DKI created by the DPS 108 to decrypt the encrypted data.

[0050] 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.

[0051] 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.

[0052] In one embodiment the device database 112 includes a collection of KCM stored as a function of the serial number or other identifying information of a device 104. In the case in which each device 104 is uniquely identifiable by a device serial number (DSN), the DDB 112 includes a stored collection of DSN[n] and KCM[n] pairs. In some embodiments the DDB 112 may comprise a global DDB containing DSN[n] and KCM[n] pairs for all devices 104 within the system 100. In other embodiments the DDB 112 may 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 devices 104 and stored within the DDB 112 in association with the KCM respectively associated with the DSN information.

[0053] Attention is now directed to FIG. 3, which illustratively represents a process 300 of creating a DKI 330. Referring to FIG. 3, a DDT 310 is comprised of T+1 elements, ordered from TE[0] (340.sub.0) to TE[T] (340.sub.T), 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 DDT 310 are used with a KCM 320 in the creation of the DKI 330. The DDT 310 may be mathematically represented as:

TABLE-US-00001 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 DDT 310 is independent from the other. As a consequence, some elements TE[n] (340) may have identical values.

[0054] Again referring to FIG. 3, the KCM 320 is comprised of M+1 elements, ordered from ME[0] (350.sub.0) to ME[M] (350.sub.M), 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 DDT 310 may be mathematically represented as:

TABLE-US-00002 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 DDT 310 is independent from the other. As a consequence, some elements ME[n] (350) may have identical values.

[0055] As shown in FIG. 3, the DKI 330 may 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 DKI 330 will equal the number of elements included within the DDT 310. The DKI 330 may be mathematically represented as follows:

TABLE-US-00003 DKI = {KE[0], KE[1],,,,KE[T]} 0 <= KE[n] <= KE_MAX 0 <= n <= T

[0056] The process 300 for creating a unique, single DKI 330 includes receiving a specific DDT 310 at a device 104. Once the DDT 310 has been received, the value of the first element TE[0] (340.sub.0) of the DDT 310 determines which element ME[n] of the KCM 320 associated with the device 104 is first read and accessed. In the example of FIG. 3 the value of TE[0] (340.sub.0) is assumed to be 1, which results in the value of KCM element addressed by this value, i.e., ME[11] (350.sub.1), being assigned to the first element KE[0] (360.sub.0) of the DKI 330. Similarly, the value of the second element of DDT (TE[1] (340.sub.1 of DDT 310) is used to read the value of the KCM element (ME[x] of KCM 320) addressed by this value. This KCM element value is assigned to the second element of the DKI (KE[1] (360.sub.1) of DKI 330). The same procedure repeats for the next element until the last element (TE[T] of DDT 310) is processed. The resulting DKI 330 has the same number of elements as the DDT, with the value of each such element being collected from the KCM 320.

[0057] Attention is now directed to FIG. 4, which depicts a process 400 for manufacturing and transferring KCM to individual devices 404 such as, for example, sensor devices. In one embodiment a single KCM[x] 412 is stored in a non-volatile memory of a single device 404 via a JTAG interface 424 of a manufacturing jig 420. The same KCM[x]412 is also stored, under the control of an application 430, in a DDB 440 of a manufacturing server 402. This may be done during manufacturing of multiple devices 404 where each device 404 may have the same or different KCM 412. In this embodiment, a most-likely-unique KCM 412 is generated in the manner described below and stored for each device 404. The DDB 440 stores all pairs of KCMs 412 and DSNs 408 for all manufactured devices.

[0058] 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 server 402, 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.

[0059] 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.

[0060] Turning now to FIG. 5, there is illustrated a sensor system 500 including a plurality of sensor devices 504 configured in accordance with an embodiment. As shown, the sensors 504 are in wireless communication over Bluetooth Low Energy (BLE) connections with a BLE host 524 instantiated at an aggregation point 520. In one embodiment the BLE host 524 communicates with a local “cloud” comprised of a local application 530 executing on a server component 502 in communication with, or containing, a DDB 540. Each sensor 504 generally has a single KCM stored in flash memory and a unique DSN. The DDB 540 also stores the KCM and unique DSN associated with each sensor 504. The aggregation point 520/BLE host 524 may be configured to appear to the sensor devices 504 as a “BLE Host”. In this embodiment each sensor device 504 is connected as a “BLE Peripheral” over one of multiple BLE connections.

[0061] 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 point 520/BLE host 524 may be implemented using a Nordic Semiconductor PCA10000 V2.2.0 USB board configured as a BLE version 4.0 Host. The local server 502 may 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 host 524 may establish with each sensor 504 (based on its DSN[n]) a standard BLE version 4.0 (or later version) Host to Peripheral connection.

[0062] During operation of the system 500, the BLE host 524 is configured to authenticate each of a set of n sensor devices 504. The process of authenticating a sensor device 504 having a specific DSN 508 is initiated when the BLE host 524 sends data encrypted in the manner described below (“e-Data[n]”) to the device 504. 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.

[0063] As part of this authentication process, the BLE host 524 generates 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 host 524 to 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.

[0064] Considering now the details of an exemplary authentication process, the following authentication protocol may be executed between the BLE Host 524 and each sensor 504 being authenticated: [0065] 1—BLE Host 524 sends, encrypted with DDT[1], e-Data[1] and DDT[1] to sensor 504. [0066] 2—Sensor 504 decrypts e-Data[1], using DDT[1], into Data[1]. [0067] 3—Sensor 504 manipulates Data[1] in a pre-determined way: [0068] 3A—Each Data[1] byte is reversed into m-Data[1]. [0069] 4—Sensor 504 sends, encrypted with DDT[1], e-m-Data[1] to BLE Host 524. [0070] 5—BLE Host 524 decrypts e-m-Data[1], with DDT[1], into m-Data[1]. [0071] 6—BLE Host 524 verifies that m-Data[1] corresponds to Data[1]. [0072] 7—Above steps repeat for the rest of the set. [0073] 8—Authentication of sensor 504 verified if all m-Data blocks correspond to original Data blocks.

[0074] Referring now to FIG. 6, there is illustrated an exemplary message sequence 600 between the BLE host 524 and one of the participating sensors 504. As shown, the BLE Host 524 sends a DDT[n] to the sensor 504 with DSN[n], where n corresponds to the one of the participating sensors 504 (stage 604). In the case of the first DDT[n] which is sent (i.e., DDT[1]) by the BLE host 524 to the participating sensor 504, the sensor 504 uses that DDT[1] to generate DKI[1] using KCM[n] (stage 608). The sensor 504 in turn and uses DKI[1] to encrypt the 1.sup.st packet of data to be sent to the BLE host 524 by the sensor 504 (stage 612). In one embodiment DKI[1] is used as the key for 128-AES encryption performed during stage 612. The sensor 504 then transmits the encrypted data packet to the BLE host 524 (stage 616). Upon receiving this encrypted packet, the BLE Host 524 uses DDT[1] to generate DKI[1] (stage 620). The resulting DKI[1] is then in turn used to decrypt the 1.sup.st packet of data (stage 624). In one embodiment DKI[1] is used by the BLE host 524 as a key for 128-AES decryption during stage 624. Stages 604 though 624 are then repeated with respect to each new DDT[n] until the sensor 504 has completed transmitting all data desired to be conveyed to the BLE host 524.

[0075] Turning now to FIG. 7, a flowchart is provided of an exemplary encryption process 700 carried out by a device configured with a DPS. In the example of FIG. 7 the 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 (stage 704), it checks to determine if it has received a DDT from the host and waits for a DDT if none have yet been received (stage 706). 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 (stage 710). The DPS then encrypts the data using the DKI (stage 714) and presents it to the device. The device then sends the resulting encrypted data packet upstream to the other entity (stage 720).

[0076] Attention is now directed to FIG. 8, which illustratively represents a system 800 incorporating a host server 802, an access point 830, and a plurality of devices 850 configured for data protection in accordance with the disclosure. In one embodiment each device 850 includes a wireless transceiver and, for example, a sensor configured to produce sensor data. As is discussed below, the embodiment of FIG. 8 is particularly useful in applications involving, for example, the Internet of Things (IoT) and other applications in which an economical and secure deployment is desired.

[0077] As shown, the host server 802 includes a DPS 814, an application 810 and a DDB 812. Each device 850 also includes a data protection server 860. During operation, each device 850 receives DDTs from a DPS 840 of the access point 830 and uses its local DPS 860 to generate secure data in the manner discussed above. That secure data is then transferred to the access point 830, at which it is decrypted by the DPS 840. In like manner the access point 830 receives DDTs from the DPS 814 associated with the application 810. This enables the DPS 840 of the access point 830 to encrypt and transfer the data received from the devices 850 to the DPS 814 through a network represented as cloud 820. Application 810 may use DPS 814 to authenticate the access point 830 and the devices 850 in the manner described herein. The DPS 814 also decrypts the encrypted data received from the access point DPS 840.

[0078] The system 800 is designed to support a number of specific use cases. For example, the system 800 may form part of a home security system in which the devices 850 comprise security devices connected to access point 830 via Bluetooth protocols. In this case the devices 850 may 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 point 830 continuously communicates with the devices 850 via Bluetooth using the secure DPS protocol described herein. The access point 830 may be connected to the “cloud” 820 via on-board cellular modem. The connectivity to the “cloud” 820 can 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 server 802 may 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 devices 850.

[0079] In another use case the system 800 may form part of a payment system in which the devices 850 comprise “smart” plastic cards and the access point 830 comprises a point of sale (POS) terminal. Each device 850, i.e., “smart” plastic card, includes on-board DPS 860 in communication with the DPS 840 of the access point 830, 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.

[0080] The system 800 may also be utilized in connection with the management of retail beacons. In this embodiment a large retailer may employ numerous inexpensive, low power communicating devices 850 throughout the store floor. These devices 850 communicate with an Access Point 830 that is part of the local management system and configured with a DPS 840. These devices 850 may display items prices and managed by the store. The authenticity of these devices 850 is verified via on-board DPS 860 in order to prevent, for example, a situation where the retailer may purchase additional devices made by an unlicensed vendor.

[0081] In yet another use case the system 800 may 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).

[0082] Attention is now directed to FIG. 9, which illustrates an alternative process 900 for generating cyphertext 934 from cleartext 930 using a DPS 902 in accordance with the disclosure. The alternative process 900 is similar to the process 200, but includes additional complexity to enhance data protection. In one embodiment the DPS 902 may include a packet assembly module 916, a random number generator 918, increment only counters (not shown) and other security enhancement circuitry and methods. In cases in which, for example, the cleartext 930 is 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 module 916 to create new packets including the cleartext 930 and random data from the random number generator 918.

[0083] As shown in FIG. 9, a dynamic data token (DDT) sent by an entity is received by a device including a DPS 902 (stage 924). Upon determining a DDT has been received, the DPS 902 generates a dynamic key instance (DKI) using the DDT and key creation material (KCM) 910 stored by the DPS 902 of the device 104 (stage 920). 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 (stage 928). The encryption of the cleartext 930 using the DKI may be performed using conventional encryption schemes such as, for example, the Advanced Encryption Standard (AES) algorithm. The encrypted data 204 is then sent to the host server 102 via an interface 226, which relies upon a corresponding DKI created by the DPS 108 to 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.

[0084] FIG. 10 illustrates an exemplary sensor device 1002 configured to implement the DPS security protocol in accordance with an embodiment. The device 1002 includes standard components such as a processor 1010 connected to input/output devices 1012 via a bus 1014. The processor 1010 can 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 devices 1012 may include a sensor 1037, General Purpose IO (GPIO) (not shown) and the like. A network interface circuit 1016 is also connected to the bus 1014 to provide connectivity to a network 1017. A memory 1020 is also connected to the bus 1014. The memory 1020 includes sensor data 1022 collected by the sensor 1037 and instructions executed by the processor 1010. In particular, a DPS module 1024 is stored in memory 1020. The DPS module 1024 includes 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 in FIG. 10.

[0085] The memory 1020 can 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 memory 1020 is illustrated, the memory 1020 may comprise one or more separate memory devices. For example, in order to enhance security the DPS module 1024 could be instantiated in a physically separate and secure memory. Alternatively, the DPS module 1024 could comprise a separate integrated circuit including dedicated processing and memory resources. Alternatively, the DPS module 1024 can be part of an integrated secure zone of a security process IC.

[0086] Referring now to FIG. 11, there is illustrated an exemplary host server 1102 configured to implement the DPS security protocol in accordance with an embodiment. The server 1102 includes standard components such as a processor 1110, a LAN interface 1112 and a network interface circuit 1116 mutually connected via a bus 1114. The LAN interface 1112 enables the host server 1102 to communicate with a DDB 1134 and the network interface circuit 1116 provides connectivity to a network 1117. A memory 1120 is also connected to the bus 1114. The memory 1120 includes instructions executed by the processor 1110 including an application module 1122 and a DPS module 1124. During operation, the processor executes the DPS module 1124 when requested by the application module 1122. The DPS module 1124 produces decrypted sensor data 1126 in response to encrypted sensor data received via the network interface circuit 1116 from one or more sensor devices. Again, the DPS module 1124 could be located in physically separate and secure memory or, alternatively, could be implemented using a dedicated integrated circuit.

[0087] 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.

[0088] 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.

[0089] Referring now to FIG. 12, a flowchart is provided of a process 1200 for 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 to FIG. 5 (stage 1204). The host entity then sends a request for data to the client entity (stage 1208). In response to the request, the client uses its own DPS to authenticate the host in the manner described above with reference to FIG. 5 (stage 1212). Once the host has been successfully authenticated the client sends the requested data to the host (stage 1216).

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] Also, various inventive concepts may be embodied as one or more methods, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

[0097] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms.

[0098] The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”

[0099] The phrase “and/or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.

[0100] As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.” “Consisting essentially of,” when used in the claims, shall have its ordinary meaning as used in the field of patent law.

[0101] As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

[0102] In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of” shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03.