close-circle
Close
0%
0%

Laura // ISM-band WAN Messaging

Laura brings low-cost long-range encrypted 915MHz communication to the palm of your hand.

Similar projects worth following
What is Laura? It's a protocol/hardware stack that creates a 915MHz radio network for encrypted communication! It supports star and point-to-point network modes with full encryption, message authentication and automatic key exchange.

The Laura protocol is an encrypted messaging protocol that operates on Laura networks. The protocol lays out all of the network transactions, packet format, gateway operations and interfaces, and encryption standards.

The Laura hardware blocks are based around the Raspberry Pi (B+ and above) using the Laura HAT, as the Gateway (in a Star configuration), and two small devices called the Handheld and SubModule. Both devices use a combination of a LoRa radio, Atmel SAMD21 and Atmel ATAES132.

Laura can be used in many different scenarios, but it's core purpose is to provide human to human communication. It can be used for secure communication in harsh and/or remote areas without (or with poor) cellular service, can be used to securely exchange files (albeit very slowly) across long distances, can be used as a paging device, and many others. In an emergency, it could provide long range local communication in place of cellular infrastructure. The devices will be cheap, reasonably robust and have good battery life.

Laura's overall goal is to create a (small) or (large) scale communication network for people to talk to one another. A Laura Gateway can be carried in a bag, suitcase or car, and run for long periods of time on battery. It's range, security, asynchronous nature (being able to leave messages waiting if a node is unavailable), battery life and relative size make it superior to other pop-up forms of portable communication. It could easily sustain itself on a small solar panel, and is also easily compatible with people's existing devices (smartphones, laptops, etc). There should also be less collisions in the 915MHz range than commonly used higher frequencies.

Laura has several network modes. There's Star mode, where a single Gateway services all Nodes that join it. Laura also has an Internet Star mode, where multiple Star networks can link together through the Internet. Want to create your own Laura Carrier? You'd use this. The Gateways can be automatically ganged using the Laura Sync service, or can be manually linked. Then, there's Point to Point Mode, in which (only) two Laura Nodes talk to one another directly, without a Gateway.

Each Node on the network has an individual Secret Key, which protects the other Nodes if a single Node is broken. Encrypted messages have a MAC, Secret Keys are exchanged securely using Public/Private Key Encryption with the Gateway, and all messages contain anti-replay measures (Sync Secret). Every Node has a guaranteed unique serial number, also called it's UUID. It's keys are stored in the extremely secure Atmel ATAES132A Secure EEPROM. The network can be configured as "untrusted", and allow new Nodes to join seamlessly, or "trusted" where Node UUIDs are subject to approval. Message and system security are extremely important in Laura.

The Laura hardware devices are designed so they can serve as an independent Nodes, or be connected to a smarter device (computer, smartphone, etc.) for seamless communication with a Laura network.

There are two different types of Nodes. The SubModule is designed to interface with a smarter device, such as a smartphone. The Smartphone will run a Laura Client for it's platform, which will allow it to send and receive messages from the network (through the SubModule). The SubModule could also be connected to a regular laptop or desktop system, which runs the Laura Client for the same purpose. The SubModule can also be used on it's own. In this mode, the SubModule will only be able to receive messages, and send a canned reply (OK or NOK). The SubModule supports a battery, but does not yet have a battery charger.

The other type of Node is the Handheld. The Handheld is a device with a full keypad, vibration motor, buzzer and screen. The Handheld is designed to be a more phone-like device, with T9-style text input and text messaging features. It supports a battery and has a built-in battery charger.

You can read all about the protocol in the protocol specification document attached to the project! It goes into detail on the important bits and bobs of the protocol.

Laura HAT v1.0 (Gateway):

  • DS1307 i2C RTC
  • LoRa Radio
  • 0.96" OLED
  • ATAES132A CryptoAuthentication Chip
  • 5-Way Joy
  • SMA Connector
  • (PowerBoost 1000C Connector)

Laura Handheld v1.0 (Node):

  • 0.96" OLED
  • 12 Button Keypad
  • 1 Status LED
  • Atmel SAMD21
  • Vibration Motor
  • Piezo Buzzer
  • Atmel ATAES132A CryptoAuthentication Chip
  • MCP73871 LiPo Charger
  • SMA Connector
  • JST LiPo Connector
  • 32KHz Crystal for RTC (Built Into SAMD21)
  • LoRa Radio...
Read more »

document - 54.43 kB - 05/24/2016 at 19:40

download-circle
Download

  • 1 × Atmel ATSAMD21E 48Mhz ARM Cortex M0+ with USB Host/Device!
  • 1 × Atmel ATAES132A Embedded AES engine and Secure EEPROM!
  • 1 × UG-2864HSWEG01 0.96" OLED Display with SSD1306 driver!
  • 1 × HopeRF RFM69-HW High power 915Mhz Radio Module!
  • 1 × RaspberryPi Module B2 The short-lived RasPi2!

  • Project Status - 6/20/16

    Phil Herlihy06/20/2016 at 17:37 0 comments

    Hi there!

    It's been some time since my last update, I was awaiting some parts in the mail. Those parts were.... *drumroll* radios with LoRa support! It might be reasonably obvious at this point, but the name of the project is play on the name of that modulation scheme. I started with the other radio modules as a PoC, as availability of the LoRa radios was sparse for some time.

    First modules I got are the HopeRF RFM95W. They're about 3/4th the size of the RFM69 modules that I put in the original design, and the range should be much improved with LoRa. They fit right on my ESP8266 breakout boards, as the modules are of similar pitch and size. Thanks to this, I'll be able to pop them right on my test boards (with a little rewiring) and I'll be good to go.

    Adafruit also sells the Feather board with a Atmel ATMega 32u4 and RFM95W, which is tempting to grab to develop a multi-node test rig.

    Secondly, I bought some Microchip RN2903 modules, which fully integrate the radio and break out a UART for communication. They've also got a boatload of GPIO. These might be overkill for this application, but I'm going to run some tests anyway. I'm working on a breakout/testing board for these, which should arrive relatively soon.

  • Prototypes Progress - 5/26/16

    Phil Herlihy05/26/2016 at 21:56 0 comments

    Hey!!

    Made some good progress since last check in on the hardware prototype devices.

    I received my ATAES132s, and I finished wiring the SubModule board! I threw some OLED test code on the Zero and ran I2C Scanner to verify everything is happy on I2C. Still have to verify that the HopeRF modules work on both the HAT prototype and the SubModule prototype, but I'm 95% of the way ready to start writing some software/firmware.

    I plan on busting out my RTL-SDR module for some basic RF analysis, so I can get some insight into how well the prototypes are performing. I also put in an order for some Microchip RN2903 LoRa modules to start prototyping using those radios in place of the HopeRF RFM69-HW. I'm going to be running that effort in parallel, as it seems like the LoRa modules will have better overall range than the RFM69-HW modules, but I won't have my hands on any for another couple of weeks. Also, due to their size, I will have to re-evaluate some of my mechanical decisions, but for the most part not much should change.

    Now, pictures!!

  • Protocol Specification v0.1

    Phil Herlihy05/24/2016 at 19:52 0 comments

    Hi there!!

    Today I uploaded the latest protocol specification. It's got a lot of the important bits laid out such as the Gateway database table layout, Packet format and specification, operational characteristics, and the transaction base for a Trusted Star network. There are some very important bits missing still, like the AES encryption details, public/private encryption details, and sync secret details. These will be added in the coming weeks, as I have more time to dive into the implementation details. I've got these planned out, but would rather keep them out of the specification until I've completed a thorough second pass. I'm also working on transaction flowcharts, which will be included in the next protocol specification.

    I included the license for the Protocol (and entire project, really) in the Protocol Specification document. Yay, MIT License! The entire project will be open source. Board designs, protocol, code, etc. It going to be lots of fun.

    Attached is a small diagram for a Star network. There's not much to it, but it's a helpful, if simple, visualization of how a Laura network would be physically setup in Star mode.

  • Monitor Mode - Testing Strategy

    Phil Herlihy05/22/2016 at 17:51 0 comments

    Hi there,

    I thought I would talk a bit about my strategy for testing and verifying the operation of the modules.

    Firstly, I have two Moteino R4 boards with RFM69HW radio modules installed on them. By putting these modules into monitor mode (disabling the packet address checks), I can examine the packets that are traversing the network. I will attempt to attack the Nodes using a PC and Moteino, by maliciously crafting packets, attempting replay attacks, and exercising other protocol attack strategies.

    I have written up a model for a protocol fuzzer/test suite, which will iterate through the possible transaction scenarios (i.e. Dropped ACK, Transmit failure, ACK receive failure, Out of range, Bad destination, etc...) to exercise all of the paths. It can be run from a Linux system, with a SubModule connected to it (for -> Gateway tests), or straight from the Gateway (for -> Node tests).

    It should be possible to detect obnoxious style attacks, such as general packet flood, excessive malformed packets (fuzzing), failed replay attacks, etc. Notifications could be dispatched to a particular Node when these events occur. There's an absolute limit to the power available on the Nodes, so the network will always be somewhat vulnerable to DoS style attacks. But, these attacks will be included in the testing, regardless.

    I also have an RTL-SDR setup that I can use for light RF analysis and deep packet decoding, if need be. For the time being, I don't think I will need this level of inspection. This will help when I perform absolute range tests.

  • Prototypes Progress - 5/19/16

    Phil Herlihy05/19/2016 at 22:30 0 comments

    Hi there,

    Some things have changed a little bit since last update. I dropped the SAMD20 Xplained Pro boards for an Arduino Zero (as this is an exact match for the chip I'm using, the SAMD21). There's only a couple small differences between these two chips, but I'm a stickler for equivalent prototypes. As far as the boards themselves go, they both use the Atmel EDBG, and should work similarly. I'm going to make the Zero wiring/bootleg shield I made modular, so I can plug the Handheld or Submodule test boards into it.

    I ditched my initial Submodule prototype because of the above and below reasons, so that's back down to 20% hardware complete.

    I had some good luck, and my ESP8266 breakout boards JUST reach the pins on the HopeRF modules. (They're a little short, but I made up the difference.) So, rather than running a ton of wires for the prototypes, I have clean, veroboard mount, and pluggable modules now. You can see them in the pictures. A couple of the pin names even matched. I also had RP-SMA Launch connectors laying around that fit my veroboard. So, I can use the antenna I intended to use, and perform some other experiments. I expect that the initial prototypes will have awful RF performance because of the breadboard/connectors/hand wired antenna connector, but they're only serving as PoC, so no worries.

    I'm almost done wiring up the Gateway prototype, 90% of the way. You might notice something important is missing. The ATAES132? Yeah. I overnighted a batch from Digikey, so they should be arriving tomorrow. Once I get that on, I can write some sweet sweet Gateway code.

    Way at the bottom is the progress on the Submodule test bits. Parts are soldered in place (into female headers, really), but not wired yet. I'll knock that out (hopefully) tomorrow when I have the AES chippies in hand.

  • Project Status - 5/13/16

    Phil Herlihy05/13/2016 at 22:42 0 comments

    Hi there,

    This is my first progress report after taking the wraps off of Laura. So far:

    Hardware Progress:

    Establishing a working SubModule prototype using on-hand parts (SAMD20 Xplained Pro x2, HopeRF modules, ATAES132A on Breakout): 40% complete.

    The remaining 60% is all firmware that must be developed for the SAM to exercise all of the hardware and perform point-to-point tests. Once those tests pass, I will build upon this firmware to bring it to Alpha level for testing on actual hardware prototype boards.

    Esablishing a working Gateway prototype using on-hand parts (Raspberry Pi 2, HopeRF modules, ATAES132A on Breakout): 10% complete.

    Completed research on proper device hookups, prototype plan and tests written, basic code skeleton established.

    Laura HAT v1.0:

    Second pass board design complete. Needs placement tweaks, alignment, stitching. Prototype verification needed in order to release third pass to fab once complete.

    Laura SubModule v1.0:

    Third pass board design complete. Full prototype verification needed in order to release third pass to fab.

    Laura Handheld v1.0:

    Second pass inspired me to rip up the entire layout and start from scratch. The mechanical outline has been established and preliminary component placement is set. So, back to zero passes for now. More to come.

    Gateway Software:

    Started tweaking the base Rasbian Jessie Lite image to meet the requirements for the security of the Gateway and for a read-only root partition. Defining list libraries and utilities that will need to be installed into the image to proceed.

    SAM Firmware:

    PoC plan and tests written. Researching and shaking off some cobwebs for coding the routines necessary efficiently.

View all 6 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates