Back to blog

Introducing Masked Authenticated Messaging

At its core, IOTA uses a gossip protocol to propagate transactions through the network. This mechanism means that any data with sufficient weight can be dispersed to the opposite side of the cluster efficiently. These transactions can carry value or data sent from a car, a cargo ship, or an app on your phone — allowing any device or human to send messages across the globe.
What is Masked Authenticated Messaging
An experimental module currently under peer review, Masked Authenticated Messaging (MAM) is a second layer data communication protocol which adds functionality to emit and access an encrypted data stream, like RSS, over the Tangle (IOTA’s distributed ledger) regardless of the size or cost of device. IOTA’s consensus protocol adds integrity to these message streams. Given these properties, MAM fulfills an important need in industries where integrity and privacy meet.

In IOTA, a user can publish a message at any time. They only need to conduct a small amount of proof of work to allow the data to propagate through the network (This is necessary to prevent spamming of the network). If nodes are listening for the channel ID (= address) in real time, the message (gossipped through the network) will be received by a subscriber when it reaches the subscriber’s node.
These messages can have any size; however, a heuristic evaluation would demonstrate smaller messages yielding higher potential for data integrity. For example, one could transmit an encrypted 4k video using MAM but this will saturate the network leading to a lagging user experience. Therefore it is more efficient to use MAM to signal some off-tangle protocol for the actual streaming. Other concepts that would find a great advantage in MAM include transmitting remote control commands and orchestrating updates.
Since these messages are part of the distributed ledger, they both contribute to the security of the network by increasing total hashing power and benefit from the data integrity properties of the network as other transactions continue to indirectly reference them.

Existing functional examples of MAM being utilised on embedded devices are the Bosch XDK IoT developer kit or the RuuviTag, an open source sensor beacon from Ruuvi Labs. Using the XDK or RuuviTags, one can create portable weather stations, Eddystone proximity beacons, vehicle locators and many other nifty sensor applications that report telemetry to a limited audience via the tangle or receive commands through a MAM stream. Another use case that was recently announced is an EV charging station from the Dutch energy giant Elaad, with IOTA enabled payments which allows for transparent data integrity.
In-depth
MAM uses a Merkle tree based signature scheme to sign the cipher digest of an encrypted message. The root of this Merkle tree is used as the ID of the channel. Since a single tree only lasts for a short period of time, each message contains the root of the next Merkle tree (or the future direction of the channel). Since previous trees are not referenced, this might be used to add an element of forward secrecy to a channel.

Each message is encrypted with a one-time pad that consists of the channel ID and the index of the key used to sign the message; an additional nonce may be used as a revocable encryption key. The resulting cipher hash is signed using the private key belonging to one of the leaves. The encrypted payload, the signature and the leaf’s siblings are then published to the tangle where anyone knowing the symmetric key can find and decrypt it.
When consuming a MAM stream, the message is first authenticated by validating the signature and verifying that the signature belongs to one of the tree’s leaves and then unmasked. If signature verification fails, the entire message is deemed invalid.
Privacy & Encryption Modes
MAM can be used in multiple ways to control visibility and access. I describe a few of these patterns that provide nuanced uses of MAM well beyond a simple encrypted message stream.
Public
Public mode uses the tree’s root as the address of the transaction that the message is published to. A random user to stumbling across a message can then decode it by using the address of the message.
This mode is similar to broadcasting on HAM radio. It could be used for public announcements from a device or individual and a possible use case would be a twitter clone, however now you have the added properties of immutability and data integrity.

Private
Private mode can be used for encrypted streams not meant for public consumption. In private mode, the hash of the Merkle root is used as the address. This stops a random user from decrypting your message if they stumble across it due to the fact that they are unable to derive the root from the hash. This makes a MAM stream only readable by those who are provided with the root.
This mode is more similar to an encrypted radio stream — anyone can see it, but only those who know to look for it can decrypt it. Private mode is useful for owned devices communicating privately amongst each other.

Restricted
Restricted mode adds an authorization key to private mode. The address used to attach to the network is the hash of the authorization key and the Merkle root. A message publisher could stop using the auth key without changing their Channel ID (that is, the merkle tree), so access could be in essence revoked from subscribers if desired. When a key change event occurs the new auth key needs to be distributed to the parties that are allowed to follow the stream.

Forward Secrecy
Since each message contains the root of the next merkle tree it is easy for users to follow the stream given once the current tree is exhausted if they also know the type of stream and the optional authorisation key being used. Given that a current message only points to the next merkle tree, there is no way for a user reading the MAM stream to read messages prior to the root they have been given. It’s easiest to think of a MAM stream as a freeway: when you first start to read a stream you are entering the freeway and you can’t go against the flow of traffic.

This is a simple but very useful feature when you start to think about it in combination with channel splitting.
Channel Splitting
A MAM publisher can decide to split the channel at any point in time. This means: future messages use a new Merkle tree whose root has not been revealed before. This enables offshoot channels for specific subsets of data, the entirety of which is not intended to be shared, thereby permissioning data and providing fine grained access.

Permanent Channel Split
One example could be personal identity record. This record can have two main branches: Public and Private data. The Public branch uses the Private MAM mode and lets all users who have the root read the messages. This could include name, a list of interests and a base64 encoded profile picture. When going to a physician the user can share the a substream of daily weight data. They can do this by sharing the root and auth key of the weight stream. Given that there is forward secrecy, the physician will be unable to gain access to extra data they have not been given access to.

Short lived stream split
Another approach would be short lived channel splits for data streams. A device may do a daily report on environmental data. When it detects an anomaly it then splits the channel and starts reporting data at a smaller interval. In addition to communicating values at the regular interval to the main channel, it could also notify listeners of the new split channel that contains the more frequent updates. This maintains the temporal spacing of the main stream while allowing the flexibility to add in secondary stream for special use cases.
Conclusion
Masked Authenticated Messaging is one of IOTA’s most potent IXI Modules and opens up a new field of use cases on top of IOTA. Being able to secure data’s integrity and control its access management is a prerequisite for things like Over-The-Air updates(OTA), Data Marketplaces, Fog Analytics, End-to-End verifiable Supply Chains, Automated Insurance and so much more.
comments powered by Disqus