IOTA Tutorial 19 | Masked Authenticated Messaging

IOTA Tutorial

Masked Authenticated Messaging

In this video series different topics will be explained which will help you to understand IOTA. It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.

The main objective of this video is to provide you with some basic knowledge about Masked Authenticated Messaging.

IOTA is specific developed for Internet of Things (IoT) or Machine-to-Machine (M2M) economy. IoT devices will generate a huge amount of data which can be stored on the Tangle. These IoT devices can broadcast data using different types of wireless technologies, such as WiFi, BlueTooth, LoRa, ZigBee, etc. This LoRa node transmits sensor data to a receiver, also called LoRa gateway. The LoRa gateway is connected to the Internet and sends the data to a server. This server is running a NodeJS Masked Authenticated Messaging (MAM) application which in turn sends sensor data to the Tangle.

Masked Authenticated Messaging means:

  • The message is encrypted (Masked).
  • The message is confirmed to be coming from the device (Authenticated).
  • A continuous message stream is created on the Tangle and will carry on until the device stop publishing the data (Messaging).
  • Masked Authenticated Messaging is a module build on top of IOTA that makes it possible to send messages fully encrypted from authenticated parties.

IOTA Masked Authenticated Messaging (MAM) makes it possible for sensors and other devices to encrypt entire message streams and securely store those in the Tangle each on a separate address. Only authorised parties will be able to read and reconstruct the entire message stream. In MAM only those with the right channel IDs get access to the message.

IOTA uses the gossip protocol to propagate messages through the network.

Bob publishes sensor data to the Tangle under channel id “ABC”. Alice is interested in Bob’s sensor data and subscribe to his channel id. When a message with channel id “ABC” reaches Alice’s node, she will be notified. Messages from Charlie will be ignored.

In a Masked Authenticated Messaging stream or message chain, every message holds a reference to the next message. The message stream only flows one direction. A subscriber with a channel ID has no access to the upstream messages. In a Masked Authenticated Messaging stream the message is encrypted (masked) and the message also contains a signature. The signature proves that the publisher created the message.

Interesting points to remember:

  • The channel ID is also called the root.
  • The message is attached to the Tangle using this root.
  • When the message is attached to the Tangle, the transaction does not need to be confirmed.
  • After a snapshot all messages are deleted from the Tangle. The messages are still available, if the subscriber is connected to a permanode.

A Masked Authenticated Messaging Demo: https://www.mobilefish.com/services/c… This demo uses the MAM Javascript library mam.web.js for web applications. The MAM Javascript library publish transactions to the Tangle that contain only messages, with no value.

The MAM Client JS Library is a wrapper library which uses the WebAssembly iota-bindings-emscripten.wasm file.

  •  WebAssembly is a new binary format for executing code on the web.
  • Rust is a programming language similar to C++.
  • Emscripten is a source-to-source compiler which can also produce WebAssembly.

The side_key is used to encrypt and decrypt the message. The side_key is required when using the restricted mode. The publisher publishes messages using the root. The publisher can choose the following channel modes:

  • Public: address = root Messages can be unwrapped by anybody using the address.
  • Private: address = hash(root) Messages can only be unwrapped if you have the right root, and the root can‘t be deducted from the address due to the hash.
  • Restricted: address = hash(root) Messages can only be unwrapped if you have the right root and side_key.

The MAM library creates the masked payload and calls the iota.api.sendTransfer function. The sendTransfer function in turn calls the iota.api.prepareTransfers function which divides the masked payload in smaller parts. Each part size will be 2187 trytes, representing a signatureMessageFragment. A transaction object is created for each part. The transaction objects together forms a transaction bundle.

You might also like

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More

Did you know?

Buy in without the stress of trying to time the market

when you setup a savings plan. If you haven’t started a plan yet, head to your Bitpanda account to get started!

Purchasing cryptocurrencies comes with a number of risks.
Never invest money that you can't afford to lose.

You can automatically invest

in IOTA with Bitpanda Savings!