While waiting for Jinn, that will allow micro IoT device to calculate quantum resistant signature of their transactions, I’ve been involved in an IoT project that need high level of security of many different aspects.
IOTA already provides a powerful tool for publishing data on the tangle: Masked Authenticated Messaging or MAM.
Unfortunately, MAM is perfect for all those situations where a single data source needs to securely publish data to many receivers.
In those cases where data is provided by a single source but pushed by different devices changing every time, MAM it not useful because to make it work all the entities should share the MAM channel’s state.
This is the case of a tracking system where objects are identified using RFID or NFC tags and their ID read by a RFID/NFC reader. Using MAM every RFID/NFC reader would publish data over his own channel and to follow a tag a client tool would need to listen to every readers’ channels, looking for a specific object ID.
Not an elegant solution.
In addition, a RFID reader device can be stolen and/or tampered with and his SEED copied to create an unauthorized channel publishing false data.
It is possible to detect this event by observing the data flow but it is not easy to distinguish between authorized and unauthorized flow.
So, I needed a different solution addressing these specific cases:
- Use a trustless device to securely publish a trusted tag’s data.
- Publish data from authorized trusted device.
- Revoke the authorization of a trusted device/tag that has been stolen or tampered with.
There will be three kind of devices:
- Identification tags
- Trusted tag readers (or environmental sensors)
- Trustless tag readers
Crypto Smart Card.
The solution I’ve designed is based on a crypto smart card.
Basically, a Crypto SMART CARD is the same device used in chip (or wireless) credit cards and more simply the mobile phone SIM used to securely identify an operator’s customer.
These are the capabilities of a common Crypto Smart Card:
- Chip certification: CC EAL5+
- ISO Certification: CC EAL4+
- FIPS 140–2 level 3
- ISO 7816 1–4,8,9 standard, I/O speed up to 31 cycle/etu
- Communication protocol: T=0, T=1, contactless RFID or NFC
- EEPROM 72 KB
- Cryptographic algorithms: AES-128/192/256bits, DES, 3DES, RSA
- Hash algorithm: SHA1, SHA-2, SHA-224, SHA-256, SHA384, SHA512
- RSA key lenght: 1024 and 2048 bits
- Elliptic Curve Diffie-Helman: 160/192/224/256/384/521 bits
- Algorithm Elliptic Curve DSA GFP: 160/192/224/256/384/521 bits
- Random generator: FIPS 186–2
- Secure Messaging: yes
- Netlink: HPC and PDC
- Cycles of read/write: 500.000
- Supply: 1.8 ÷ 5.5V
- Unique serial number
In simple words, this device can store 72 KB of data in a secure memory and can be programmed to execute a sequence of operations including cryptographic functions creating signatures and hashes.
It is almost impossible to access the secure memory and clone a Crypto Smart Card.
In addition to the physical Smart Card, a virtual Crypto Smart card can be defined using the security feature provided by Android, IOS, Windows or the Linux based major OS.
How to use a smart card
In theory being able to execute the SHA-256 hash function (currently used by IOTA) a Crypto SMART CARD could be able to sign a bundle hash creating a valid transaction, but this operation can be unreliable: smart card electric contacts are not designed to transfer large amount of data at high speed and executing many time the hash function many times to produce the bundle hash signature can take time. These devices are designed to work for a few seconds, as it is normal for a credit card or a mobile phone network registration.
Anyway, we can store data in the 72 Kbyte secure memory accessible only with a high level secure procedure a Private Key and use the Smart Card CPU to encrypt a string of data.
Smart card initialization
I need now to introduce the Control Center.
Control Center is an application managed by the tracking system owner that generates a couple of keys (private and public) for each Crypto Smart Card.
The Control Center owns a MAM channel where it publishes a new message, each time it initializes a Smart Card
Control Center uses a SEED to generate a Smart Card unique ID so the Smart Card initialization message includes:
- Smart Card unique ID: it is a IOTA valid address produced from a SEED using the Smart Card internal progressive ID as Key ID.
- Smart Card Public Key: RSA 1024 key used to decrypt data provided by the Smart Card, signed with the private Key.
- Associated device (tag or sensors) specification: a set of data describing the nature and the technical specification of the Smart Card’s associated device.
In publishing this message on the MAM channel, the Control Center informs every channel’s listening client that a new Smart Card has been authorized to publish data.
The Control Center MAM channel can be public or private according to the specific application requirement.
We have two cases:
- publishing data from a trustless device
- publishing data from a trusted device
Publishing data from a trustless device
Data comes from the Smart Card itself and from other sensing components (temperature, vibration, light, etc.)
The reader executes this procedure:
- The reader collects the data payload.
- Add the geographic position (autonomously evaluated) to the payload.
- Create the payload hash.
- Use the Crypto Smart Card to sing the payload using the private Key.
- Read the Crypto SMART CARD unique ID (IOTA address).
- Prepare a IOTA bundle with a number of transactions sufficient to store all the payload in the unused signature fragment fields. Every transaction uses the Smart Card unique ID as address.
- Finally execute the POW (or use an IOTA node that will execute the POW) and publish the transaction to the network.
Data published by this procedure (including the geographic position) are not trustable but the client can trust that the reader was able to interact with that specific Crypto Smart Card verifying the payload signature:
- A client tool listening to the Smart Card’s address is advised by the IOTA gossip protocol that a new transaction is available on the address.
- Reading the Control Center MAM channel the client can find the Smart Card Public Key and use it to verify the payload hash signed by the Smart Card.
This procedure allows to the tracking of Tags that can’t be cloned and allows the storage on the IOTA Tangle of much information related to the tag or the object where the tag is installed.
Publishing data from a trusted device
Suppose to have a device similar to the one previously described and able to read data from the environment (including tags).
This device is considered trusted because it owns a Crypto Smart Card initialized by the Control Center with the procedure previously described.
In addition, the device is able to identify tampering attempts: in sensing an attempt to move, open or tamper, the device will try to publish an alert message and then lock his Smart Card becoming trustless.
We have two cases:
- If the device is an environmental sensor it will execute the procedure described before for the trustless device. The client application will be able to evaluate the data confidence level identifying the reader as trustable device checking the signature with the public Key stored on the Control Center MAM channel.
- If the device is a tag reader it will publish data provided by the tag. It will execute the procedure described before for the trustless device, but in this case it will use the tag’s unique id as transaction. To highlight its presence it will add to the payload its own Unique ID to allow the client application to evaluate data confidence level identifying the reader as trustable device.
Virtual Smart Card
Some of the Smart Card features (like the cryptographic functions e secure memory) are available on any popular smart phone operating system.
Using the appropriate development techniques allows to creation of apps that can behave like a smart card allowing the identification of a smartphone as a trusted device.
What if a tag or a trusted device is stolen?
Of course, we can’t prevent a device from reading a stolen tag and publish data, but we can declare that tag as stolen and notify the clients.
Practically we revoke the tag authorization to sign data.
Once informed that a tag has been stolen the Control Center will publish a new initialization message for the stolen tag ID. In the new message the public key is set to null and the tag status is set to the appropriate value in accordance with the specific application (stolen, lost, disabled, etc.).
The tag can be used to produce data, but client applications reading the messages will identify the message as generate by an unauthorized tag.
The same operation is done in the case of a trusted device is stolen or tampered with.
The cost of a crypto smart card may vary depending on the volumes and levels of certification required from the supplier, but for the objectives of this project no special certifications are needed other than those already owned by the smart card itself.
In this case the Smart Card price can start from 8 USD each for small volumes, and be reduced as volumes increase.
IOT device Integration
The ISO 7816 standard describes the physical interface used by the smart card to interact with the external world.
Basically, it is a serial interface which lets any micro controller is able to communicate with the smart card.
The next step of this project will produce a demonstrative device able to create authenticated and authorized data.
The system I’ve designed can be described as a “Distributed Authoritative Directory of IoT devices”. It allows an organization to distribute micro devices and control them with a distributed platform.
Publishing data on specific IOTA addresses allows opens to sybil attack from malicious entities, but using the security features of the crypto smart card we can easily identify valid messages among all and deactivate any type of attack.
In the future the Crypto Smart Card will be probably replaced by Jinn feature and the Control Center can become a distributed component running as a Qubic, anyway we already have a strong solution for secure distributed tracking and sensing systems.