Encrypted messages (DTLS and TLS)
Your device can encrypt its messages with DTLS 1.2 on UDP port 41300 or
TLS 1.2 on TCP port 12400, using a pre-shared key (PSK).
No certificates are needed. The server decrypts your messages, so you see their content in the live traffic
as for unencrypted messages, together with the handshake and the cost of the encryption.
1. Get a key
On the Keys page, either let the server generate a key (you can choose the identity or let the server pick one), or enter your own identity and key (16 to 32 bytes, in hex). The key is shown only once, right after you create it: save it or download the device key file before you leave the page. A key that is not used for 90 days is deleted.
2. Configure your device
| Server | 164.30.75.205, DTLS: UDP port 41300, TLS: TCP port 12400 |
|---|---|
| Protocol version | DTLS 1.2 or TLS 1.2 (TLS 1.3 is not supported) |
| PSK identity | The identity of your key, e.g. ict-7f3k9q |
| PSK | Your key. The hex string stands for the key bytes: 0a1b… is the bytes 0x0a, 0x1b, … |
| Server verification | Not needed: with a PSK, both sides prove they know the key |
Cipher suites
The server accepts these cipher suites. Your device offers its list in the handshake, the server picks one of them.
| Cipher suite | Bytes added per message | Note |
|---|---|---|
TLS_PSK_WITH_AES_128_CCM_8 | 29 (DTLS) / 21 (TLS) | Recommended: the smallest overhead, the default of most IoT modems |
TLS_PSK_WITH_AES_128_CCM | 37 / 29 | |
TLS_PSK_WITH_AES_128_GCM_SHA256 | 37 / 29 | |
TLS_PSK_WITH_AES_128_CBC_SHA256 | 62 to 77 / 54 to 69 | Padding and a longer checksum: the largest overhead |
The bytes per message are the record header, the nonce or IV and the checksum, without IP and UDP/TCP headers. The handshake at the start of a session costs about 700 to 900 bytes in addition.
Sessions and connection ID
A DTLS session stays valid after the handshake: your device can send further messages without a new handshake, also after sleeping for several hours. The server supports the DTLS connection ID (RFC 9146): if your device offers it, the session continues even when the mobile network gives your device a new public address or port in the meantime.
When the handshake fails
The live traffic shows every handshake, also failed ones, with the reason:
| Shown reason | What it means | What to check |
|---|---|---|
| unknown identity | The server has no key with this identity | Spelling of the identity; the key may have been deleted |
| wrong key | The identity exists, but your device uses a different key | Compare the fingerprint in your device key file with the Keys page; a hex key entered as text instead of bytes |
| no common cipher suite | None of the offered cipher suites is supported | Enable one of the cipher suites above |
| unsupported TLS version | The device only offers TLS 1.3 or older than 1.2 | Use TLS 1.2 / DTLS 1.2 |
| timeout, stopped after … | The handshake did not finish; the trace shows the last message | Radio connection, retransmissions in the packet list |