Secure decoupled messaging with DANE and the TLSA resource record
Configuration
Set each device's DNS name in Balena.io by defining an environment variable called IDENTITY_NAME
for each device. This should be set to the DNS entry that will store the device certificate.
Create the device identity credentials, using a terminal session in the maintenance container, by running ./create_selfsigned_id
.py. Next, generate the TLSA record data by running generate_tlsa.py
.
You'll see a long string of text produced from the last command. That's the actual TLSA record contents for you to place in DNS (Figure 1).

You'll notice that if you run ls /identity/
, you'll see a self-signed certificate and private key. Perform the same steps for generating the identity and TLSA record for each of your devices. Then, copy the TLSA record contents for each of your devices into your DNS management system. There are a great many options for hosting DNS; you can pick a DNS hosting provider that supports the TLSA record type or you can use an open-source DNS server like PowerDNS. Once your TLSA record is correctly configured in your DNS server, you will be able to use dig to download your certificate. As described previously, enter:
dig -t TLSA ${IDENTITY_NAME}<I>
where ${IDENTITY_NAME}
is your device's DNS name.
In the Balena console, watch the logs for the messaging_receiver
service. At first, you'll see "Public identity is not valid!" messages. These messages will go away once the TTL in DNS for record nonexistence expires and the certificate is available. It shouldn't be more than a minute or two with most DNS servers.
Sending a Message
To send a message between your devices, use the messaging_sender
container to run the send_message.py
command. This command takes two arguments: the destination device's DNS name and the message itself (Figure 2). (Don't forget the enclosing quotes if the message has spaces.) When you run this command, the tool uses the device's private key to generate a signed JWS object containing your message. The tool then grabs the recipient's certificate from DNS and uses the public key in the certificate to generate an encrypted JWE object, which contains the JWS object. Finally, the signed and encrypted object is published to the message broker with the recipient's DNS name as the topic.

Within a second or two, you should see the message in the console of the recipient device (Figure 3). The recipient device listens on the message broker for messages with a topic matching the device's DNS name. The device then retrieves and decrypts the message (JWE object) and then uses the sender's certificate from DNS (which is referenced in the JWS object headers) to authenticate the message. Finally, the message is printed to the console.

These messages all pass through the HiveMQ public message broker. You can watch your encrypted messages scroll by using the web client located at http://www.hivemq.com/demos/websocket-client/. First, use the web client to connect to the broker (hostname: broker.hivemq.com
). Next, watch the recipient device's topic: Use the device's identity name for the topic to monitor.
Call a friend, and ask them to follow the same steps. It doesn't matter if you use the same domain, or if you even use the same DNS provider. They just need a certificate in a TLSA record, and you can chat with end-to-end encryption and source authentication knowing only the DNS name of the device with which you want to communicate.
Postscript
The chat application described in this article implements sender authentication and end-to-end message payload encryption in a way that doesn't require you to transmit a copy of the certificate to everyone who might need to authenticate the sender of your messages.
Compare this to the common practice of synchronizing the certificate authority's set of currently-valid certificates to every entity that might need to authenticate your messages. The method described in this article is more scalable and straightforward. Certificate rotation is straightforward too: If you want to replace your device's certificate, the only delay in rotation is tied to the time required to place the new certificate in DNS and wait out the TLSA record's TTL; the recommended TTL for the TLSA record is not specified in the DANE RFC and is completely under your control.
This system is resilient against naming collisions (since there is only one DNS), and revoking trust in an identity is as simple as deleting the TLSA record from DNS. Even though the messages themselves pass over a public transport for all to see, they are individually encrypted so that only the intended recipient may read them. Though the message is encrypted, the recipient device's DNS name is still revealed in the message topic.
The messaging devices described in this article won't add much convenience to your day-to-day life, but they demonstrate the use of standards and open source software to simplify the process of end-to-end message security in IoT applications. Remember: Encryption is only part of the solution. Without authentication, you really can't establish trust.
Standards bodies have a great deal of work ahead to address the many different aspects of secure IoT communications. The speed of evolution in those IoT-specific initiatives leads to many interesting and engaging possibilities.
Now you have patterns, tools, and examples to build on. Go forth and build better, more secure applications!
Infos
- DANE RFC: https://tools.ietf.org/html/rfc7671
- MQTT: https://mqtt.org/
- dane_jwe_jws library on PyPI: https://pypi.org/project/dane-jwe-jws/
- JOSE Working Group: https://datatracker.ietf.org/group/jose/documents/
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Direct Download
Read full article as PDF:
Price $2.95
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Find SysAdmin Jobs
News
-
LibreOffice 7.5 has Arrived and is Loaded with New Features and Improvements
The favorite office suite of the Linux community has a new release that includes some visual refreshing and new features across all modules.
-
The Next Major Release of Elementary OS Has Arrived
It's been over a year since the developers of elementary OS released version 6.1 (Jólnir) but they've finally made their latest release (Horus) available with a renewed focus on the user.
-
KDE Plasma 5.27 Beta Is Ready for Testing
The latest beta iteration of the KDE Plasma desktop is now available and includes some important additions and fixes.
-
Netrunner OS 23 Is Now Available
The latest version of this Linux distribution is now based on Debian Bullseye and is ready for installation and finally hits the KDE 5.20 branch of the desktop.
-
New Linux Distribution Built for Gamers
With a Gnome desktop that offers different layouts and a custom kernel, PikaOS is a great option for gamers of all types.
-
System76 Beefs Up Popular Pangolin Laptop
The darling of open-source-powered laptops and desktops will soon drop a new AMD Ryzen 7-powered version of their popular Pangolin laptop.
-
Nobara Project Is a Modified Version of Fedora with User-Friendly Fixes
If you're looking for a version of Fedora that includes third-party and proprietary packages, look no further than the Nobara Project.
-
Gnome 44 Now Has a Release Date
Gnome 44 will be officially released on March 22, 2023.
-
Nitrux 2.6 Available with Kernel 6.1 and a Major Change
The developers of Nitrux have officially released version 2.6 of their Linux distribution with plenty of new features to excite users.
-
Vanilla OS Initial Release Is Now Available
A stock GNOME experience with on-demand immutability finally sees its first production release.