S2CT White Paper

Data Security in the Global Supply Chain

By Jim Davis and Eric Lam, Ph.D.

The security of data communicated to and from assets traveling in the global supply chain has a number of underlying motivations. First, asset owners are interested in ensuring that no unauthorized persons gain access to their private data, for both competitive as well as liability issues. Competitive "intelligence" is pretty straight forward. Liability issues are more complex and are generally better served by a complete data picture which can often be quite different than the picture developed just from data from the assets.

Asset owners are also interested in ensuring that the data they receive from their assets in the field, is legitimate and has not been tampered with for illicit purposes. Making a container's door appear sealed when it isn't, is a good example. In the new world of connected assets, with multiple devices collecting and reporting data as they travel through the global supply chain, the opportunity for such intrusions abound. These underlying issues that drive the need for data security are too complex to be adequately addressed in this paper. Suffice to conclude, that if technology can ensure that only those that are explicitly authorized to get the data, get it, and that all of the data they get is legitimate, the issues surrounding the need for data security are addressed.

Security: make it difficult and costly, no easy targets

We point out upfront, that we don't actually believe it is possible to develop data security that can't be defeated. This has been demonstrated many times over the years since the inception and spread of personal computers and digital data stored on disk drives. This was again recently demonstrated, after these many years of effort by many companies and researchers to develop fool-proof data security, by the U.S. FBI, with help from professional hackers, cracking an Apple iPhone's security to get at its data(1). So, we approach security for the global supply chain from the perspective that making a data security breach difficult and costly is the objective. Even though the FBI was able to break the iPhone's security, it was not easy and their efforts and cost clearly demonstrate that it was the potential value of the iPhone's data that drove them. The underlying point here is that hacking has a cost to value consideration and more often than not the potential value of hacked data is what draws hackers. Hackers logically weigh the effort and cost to get targeted data against the value of the data prize. In the FBI case, it was the value of knowing what information could be brought to light by accessing the data on that particular iPhone that justified their efforts. That's not the typical case. Demonstrating the more usual case were the Amazon breaches(2) in 2015 and 2017, where the expected reward for those efforts were large amounts of data that could be monetized, consumer credit card and other personal data. The hackers were confident that at least some of the hacked data would be valuable, simply based on the volume and diversity of the data, and that there was a potential that most of it would be. Supply chain stakeholders can draw their own conclusions regarding depositing their data into central repositories where the value of a break in, is the value of the aggregate data in the repository.

Data encrypted at source

It is not an objective of this paper to present even a simple tutorial on the complex technologies of data security and encryption but for purposes of laying out the S2CT Data Security Model, for the global supply chain, we will need to describe a few of their key aspects and considerations. The aforementioned Amazon breaches and the breaking of the Apple iPhone security were certainly not accomplished by simple brute force. That is, not by finding and trying all the possible binary combinations until the correct encryption key was found. Even 128-bit encryption would take a supercomputer years to try all possible combinations to find the correct encryption key, 2128 combinations. Beyond the iPhone's data encryption, a 4-digit access pin with embedded software that would have erased the iPhone's encryption key after only 10 unsuccessful attempts, further protected its data and ruled out brute force methods. It is reasonable to conclude that the FBI in 2016, with the help of the outside hackers, the iPhone physically in hand, and reportedly special hardware developed specifically for the task, also used additional sophisticated methods to gain access to the locked iPhone's data. The S2CT Data Security Model emulates these concepts and strives to make supply chain monitoring devices equally difficult and costly for a would-be hacker to overcome.

The first line of defense is that all data is encrypted at its source, selectively with 64-bit, 128-bit, or 256-bit AES Encryption(3). Fig: S2CT Data Security Model Sensor to Cloud CableData "in-flight" is never unencrypted. A Sub GHz temperature sensor device in a truck trailer's cargo area receives temperature data from its attached sensor, immediately encrypts it, stores it in its encrypted form in its data log, and sends it in its encrypted form to an authenticated end-point destination. End-point destinations can be other authenticated Local-Area-Network devices or an authenticated designated Asset Management Cloud. Only authenticated end-point destinations can decrypt data. Several temperature sensor devices, placed strategically throughout a container's cargo area might each send their data, wirelessly, to the same authenticated Cloud Cable, also in the cargo area. The authenticated Cloud Cable decrypts, and aggregates the data from each sensor device for real-time analysis and potential consolidation. The Cloud Cable encrypts and stores its analytical output data, and potentially selected data from the sensor devices, and sends it to its authenticated designated end-point Asset Management Cloud. Again, the Cloud Cable data is encrypted as it passes through a Wi-Fi Access Point and through the Internet to its end-point destination.

Authentication is a must when sending or receiving data

The second line of defense is that data can only be sent to or received from authenticated devices through the mutual exchange of authentication keys. Fig: S2CT Data Security Model AuthenticationA device that wishes to send its data to another device or the cloud must authenticate itself to the destination and authenticate the destination. Fig: S2CT Data Security Model Cloud AuthenticationWide-Area-Network devices like Wi-Fi Access Points and other broadband communications connections are authenticated as encrypted data pass-through devices using standard security methods. Clouds, ultimately servers connected to the Internet, that these pass-through devices connect and send data to, are authenticated using S2CT's standard mutual exchange of authentication keys security method.

Own random-based authentication key for each device

The third line of defense is rooted in the idea that each device in the network is independently protected with its own random-based authentication key that is only exchanged with devices it is setup to communicate with directly. Randomness is hard to achieve but is essential to strong key security. The S2CT model achieves this randomness for every device at the device level. Device authentication keys are changed randomly over time based on an algorithm that manages the random periods between the changes as well as the key and key structures themselves. Each device's key generator is programmed to generate a new key after a randomly set period of time, based on the coincidence of random device events and data. The time when the tenths place value in the device's internal temperature data is equal the tenths place value in the device's ambient temperature sensor data and the minutes value of the device's clock time is an even number. When these events and data values are coincident, the device's key generator then uses this same random data to generate the device's new random number authentication key, select the events and data that will be used to generate the next key, and the minimum period before the next change key cycle begins.

Device level authentication begins at manufacturing when a "production" random authentication key is generated, encrypted and stored in the device and the device owner's Asset Management System's device installation manager's secure database. Devices are never openly vulnerable. The Asset Management System communicates the device's "production" authentication key to selected devices already in the field, in anticipation of the device's installation, or alternatively when an already installed and authenticated device request verification of a "new" device, when it tries to connect, from the cloud.

A little extra: random data breadcrumbs

After all this, the security of each device comes down to a random number, a random sequence of 1's and 0's, strengthened by frequently changing that number and limiting a breach to just a single device. To strengthen this security even further, our fourth line of defense introduces a random data breadcrumb into the security stream. The breadcrumb requires the device being authenticated to execute an action to retrieve a small piece of data that was previously sent and return it to the requesting device along with its authentication request. This introduces a unique multi-device time element into the security method and greatly increases the difficultly of breaching the device's security.

Data sharing: a pillar for success

So far, we have discussed how the S2CT Data Security Model makes it difficult to hack data from individual asset monitoring devices deployed and traveling in the global supply chain by independently protecting each of the devices. The next element of data security that must be addressed is in the cloud. This is probably where the data is most vulnerable or at least most targetable. On the other hand, driven by that vulnerability, this is where most of the security technology is focused with firewalls, passwords, AES encryption, SSL secure links, virtual private network connections, etc. The S2CT Data Security Model does not bring much to this area of security technology and rather depends on the biggest corporations in the world, offering cloud virtual servers and services, to provide these important security technologies. One exception is in the area of data sharing, in our minds, a pillar for success of companies operating supply chain related businesses. Here, S2CT brings a lot to the table, namely, the S2CT Dynamic Secure Data Sharing Network.

S2CT Dynamic Secure Data Sharing Network

We won't describe the intricacies of what and how the S2CT Dynamic Secure Data Sharing Network operates but will touch upon what makes it safe and reliable from a data security perspective. Fundamentally, the Data Sharing Network links two virtual clouds together, when their supply chain interests intersect, and shares data selected by each data owner with the other until their interest-intersection comes to an end. This temporary link is dealt with, from a data security perspective, in much the same way two communicating devices are dealt with in the S2CT Data Security Model.

The two Data Sharing Network clouds are linked, peer-to-peer, through a Virtual Private Network (VPN) connection. The data selected by each data owner is shared with the other using a dual "random-key" encryption model, similar in concept to a Public Private Key pair. Because the keys in the pair are mathematically related, whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa. One key is passed through the peer-to-peer data-connection and the second key through a Data Sharing Security Manager cloud connection. These keys are randomly generated and change over time. The Dynamic Secure Data Sharing Network's operation and deeper details of its security will be covered in another S2CT paper in the coming weeks.

S2CT Data Security Model

The S2CT Data Security Model is illustrated here,

S2CT Data Security Model

Key Points of the S2CT Data Security Model:

  • Strong Data Encryption at the data's source
  • Strong device-level random number authentication, coupled with time and action based data breadcrumbs
  • Device-level authentication keys and data breadcrumbs are randomly changed using the random coincidence of device-level events and data
  • Only data from authenticated devices is propagated to protect against false data insertion from rogue devices
  • Bidirectional device to device and device to cloud authentication
  • Cloud to Cloud Data Sharing using data security methods similar to that used by devices for device to device communications

S2CT's intent is to make it very difficult to break an asset's data security and to further ensure that any unlikely break-in only exposes the minimal data of a single device, very low value for high effort and cost! At the same time, we want to ensure that this data security can be successfully implemented on the simplest and least expensive asset monitoring devices, like microcontrollers and Raspberry Pi class Cloud Cables.

(1) https://www.washingtonpost.com/world/national-security/fbi-paid-professional-hackers-one-time-fee-to-crack-san-bernardino-iphone/2016/04/12/5397814a-00de-11e6-9d36-33d198ea26c5_story.html

(2) https://www.scmagazine.com/hackers-compromise-third-party-vendor-amazon-accounts/article/649665/


(3) The Advanced Encryption Standard, or AES, is a symmetric block cipher chosen by the U.S. government to protect classified information and is implemented in software and hardware throughout the world to encrypt sensitive data.