RAAM - Random Access Authenticated Messaging

RAAM is a second layer data communication protocol for IOTA, enabling protected data stream access and publishing, organized in so called channels.

RAAM uses the same quantum-resistant signature scheme and hash function used in IOTA to sign transactions. These techniques enable the construction of secure data channels providing data integrity and authorship authentication. Furthermore the data is encrypted and, hence it is stored on the tangle, immutable. By using optional passwords for a channel or for specific messages reading access can be limited to a specific private audience. RAAM can be used without any changes to IOTA nodes. Each message strenthens the IOTA network, because RAAM messages at their core are a set of zero-value transactions, confirming other transactions on the tangle.

The messages in a channel do not have to be accessed from first to last, but can be accessed in any random order in O(1). For that only the channel id and the index of the message are needed.

Features

• indexed messages
• access of arbitrary messages in O(1)
• authentication (proof of authorship) and spam protection of channels
• 4 different security levels
• private mode with channel password
• public mode with finding messages by address
• encrypting different messages with different passwords
• subscribing to new messages in channel
• constructing messages and publishing them later
• channel branching

RAAM enables messaging for a variety of use cases which need privacy and integrity for data communication. This includes M2M communication for the IoT in consumer electronics as well as in machines in industrial contexts, such as autonomous data marketplaces, supply chains, mobility and smart cities.

This JavaScript library acts as a reference implementation showcasing the specified abilities of the protocol.

Basic usage

After downloading and importing the library into your project it will provide access to all functions for reading and writing from/to RAAM channels.

Generating a new channel and publishing a message

const RAAM = require('raam.client.js');
const iota = require('@iota/core').composeAPI({
  provider: 'https://node.deviceproof.org'
});
const seed = "DONTGIVEYOURSEEDTOANYBODYELSEDONTGIVEYOURSEEDTOANYBODYELSEDONTGIVEYOURSEEDTOANYBODYELSE";

(async () => {
  try {
    const raam = await RAAM.fromSeed(seed, { security: 1, height: 4, iota });
    await raam.publish("HELLOIOTA");
  } catch (e) {
    console.error(e);
  }
})();

Reading from a channel

const { RAAMReader } = require('raam.client.js');
const iota = require('@iota/core').composeAPI({
  provider: 'https://node.deviceproof.org',
});
const channelId = "Y9FFZOE9VAOJYBMBISYDMZDWVO9ITKX9WPKUN9AESERDXLHZFAQRNJLNH9QERJWFHFFRLNO9ODSTOAVOW";
const raam = new RAAMReader(channelId, { iota });

(async () => {
  try {
    let response = await raam.fetch({start: 0, end: 2});
    console.log(response.messages);
  } catch (e) {
    console.error(e);
  }
})();

Take a look at the API Reference to learn more.

How it works

Due to Winternitz one time signature scheme used in IOTA, you need multiple signing keys for multiple messages. A reader can verify the integrity of a message by using the verifying key included in the message.

A reader can also verify, that a message has the same author than all other messages in the channel, which is called authentication. For that, RAAM uses a Merkle tree signing scheme, where the verifying keys of all messages in a channel are the leafs of the tree. From all verifying keys the root of the tree, the Merkle root, is constructed, which acts as the id for a RAAM channel.

Therefore, someone who publishes a message in a RAAM channel must not only possess the key that signed this message, but all other signing keys for the channel as well. To authenticate the authorship of a message the Merkle root is reconstructed by using the verifying key of the message and other parts of the tree, which are provided aswell. Since the Merkle root is generated by hashing, it is impossible to reconstruct certain leafs (verifying keys) from a given Merkle root, the same way it is impossible to forge a signing key from a given verifying key. This way it is easy to ensure that two different messages in the same channel belong to the same author.

Because of that the maximum amount of messages that can be published in a channel depends on the size of a Merkle tree, which has to be created in advance.