a roughtime server. just set up a public roughtime server running on OVH cloud (located in Frankfurt). The server supports protocol version IETF-Roughtime (draft-11) and Google-Roughtime. I pre-paid it for 2+ years and deleted my ssh keys, so it’s destined to run unattended on autopilot until it dies. The VPS has 91 MB of RAM, with 46 MB currently free. And that’s a lot!

You’re welcome to try it out.

• Host: 57.129.106.133:2291
• public key: H6smrxZ2VlNhxSlKmX8C92TUYnyC04FbUa94W1OynJs=

Big-key public key encryption. Here we design a public-key encryption system with “short” public keys (32 bytes) and very long private keys. The basic idea is to use an identity-based encryption scheme (like Boneh–Franklin) under the hood. The following explanation assumes you have a standard IBE with IBE.Setup(), IBE.Extract(), IBE.Encrypt() and IBE.Decrypt() operations.

Setup phase

1. Master Key Generation (Alice)
   • Alice runs IBE.Setup() → generates (MPK, MSK)
   • MPK becomes Alice’s public key (published/distributed to everyone)
   • MSK is kept temporarily for key extraction only
2. Identity Pre-Agreement (Alice & Bob)
   • They agree on a large set of identities, e.g.:
     • “alice-001”, “alice-002”, …, “alice-100000”
     • Could be: sequential, random strings, UUIDs, etc.
     • Each identity represents one decryption capability
   • Both parties store this list of valid identities
3. Big Private Key Generation (Alice)
   • For each agreed identity ID_i, Alice runs: SK_i = IBE.Extract(MSK, ID_i)
   • The “big private key” is the collection: BigSK = {SK_001, SK_002, ..., SK_100000}
   • CRITICAL: Alice then securely wipes MSK from memory/storage
   • MSK is never stored long-term, only used during setup

Encryption (Bob → Alice)

To send message M to Alice:

1. Bob picks an identity at random from the pre-agreed list
   • E.g., randomly select "alice-047851"

2. Bob encrypts using IBE: C = IBE.Encrypt(MPK, "alice-047851", M)

3. Bob sends to Alice: (C, "alice-047851")

   The identity must be included so Alice knows which key component to use

Decryption (Alice)

When Alice receives (C, ID):

1. Alice looks up the corresponding private key component from her big key
   • E.g., if ID = "alice-047851", retrieve SK_047851

2. Alice decrypts using IBE: M = IBE.Decrypt(SK_047851, C)

3. (Optional) Alice can delete SK_047851 after use for forward secrecy

Drawbacks

• It’s not “all or nothing”. An attacker that exfiltrates a portion of the private key gets a non-zero chance of decrypting ciphertexts to Alice (probability proportional to what they managed to exfiltrate).

Prototype implementation

Can be found here: https://github.com/oreparaz/bigkey-pke

Some notes:

• This implementation uses vuvuzela crypto (https://github.com/vuvuzela/crypto/blob/master/ibe/ibe.go) which uses Barreto-Naehrig curves. These are weaker than expected: see https://moderncrypto.org/mail-archive/curves/2016/000740.html
• We could use other libraries (maybe over BLS curves), like https://github.com/encryption4all/ibe/

Our threat model is remote-only attacks, with ability of performing zero-click remote-code execution (mercenary spyware).

The basic idea

light is an endpoint architecture: three independent nodes connected by unidirectional links. On top of this endpoint architecture, we implement public-key cryptography to encrypt+authenticate messages between peers. The nuance here is how each “endpoint” is constructed.

A conventional secure messenger does everything in one machine: parse untrusted network input, run crypto, handle keys, render + store plaintext, accept keyboard input.

light doesn’t do this. Instead, light carefully decomposes this monolithic networking + cryptographic stack into 3 different hardware-isolated nodes, connected via unidirectional links (data diodes).

System architecture

Each endpoint is partitioned into three discrete nodes:

• a TX computer (“the source”): takes plaintext you want to send, encrypts/authenticates it, outputs ciphertext and sends it to the GW. This computer isn’t connected to the internet. Even though it can send messages to GW, it cannot receive any bit of information from GW.

• a RX computer (“the sink”): receives messages from GW, decrypts and displays plaintext on a dedicated display. RX can only receive messages to GW, it cannot send any messages to GW.

• a GW computer (an untrusted “proxy”): this computer is connected to the internet and is connected to RX and from TX. Its task is to talk to other peers’ GWs and send/receive encrypted messages. This GW can use any transport layer: Signal messaging, XMPP, or other more sophisticated systems to provide better anonymity (tor, etc).

                              INTERNET
                                 │
                                 │ (bidirectional)
                                 │
                            ┌────▼────┐
                            │    GW   │ (untrusted proxy)
                            │         │
                            └─┬───────┘───────┬
                              │               ▲
                              │               │
                   encrypted  │               │ encrypted
                   (to RX)    │               │ (from TX)
                              ▼               │
                       ┌──────────┐   ┌──────────┐
                       │    RX    │   │    TX    │
                       │ (sink)   │   │ (source) │
                       └────┬─────┘   └─────▲────┘
                            │               │
                            │               │ plaintext
                            │               │ (input)
                            ▼               │
                      ┌──────────┐    ┌──────────┐
                      │  Screen  │    │ Keyboard │
                      │          │    │          │
                      └──────────┘    └──────────┘
                                            ▲
                                            │
                             ┌─────────────┐│
                             │    Human    ││
                             │  Operator   │┘
                             └─────────────┘

There’s an additional unidirectional link from TX to RX. This is used to send direct keystrokes and have a smooth UI.

Note that the set of 3 computers work together, and this is abstracted away to the user. The user experience is identical to that of a regular computer (one keyboard, one display).

System security properties

The trick is that the links are unidirectional. Observe that:

• TX never sees untrusted input. This means this computer will always execute the original code, and it’s impossible to remotely exploit it. Egress messages will always be encrypted to the intended recipient.

• RX does not have an egress path to the internet. This means that if this computer gets compromised, it’s impossible to exfiltrate keys or plaintext from this computer. The only “output” from this computer is a screen.

An attack: human-in-the-loop social engineering

Note that there is an exfiltration path to the internet: via the human operating the node. A compromised RX node can’t send bits to the GW, but it can send bits to the user’s brain (by lying on the screen). For example, a compromised RX could display “Sync error. Please type the following ‘session recovery code’ into your TX terminal to reconnect: [hex-encoded private key]”.

There are two ways to mitigate this:

1. Prevent that from happening with operator discipline. Train them in possible ways to trick them.
2. Even if it happens, make exfiltration astronomically slow by using big-key cryptography

Big-key cryptography means using very long private keys. Instead of 32-byte keys, use (say) a 10MB private key. Exfiltrating a 10MB key with a human in the loop is so expensive and slow that exfiltration isn’t practical.

Cryptographic constructions

The baseline construction is just public-key authenticated encryption (for example, using ECIES). This works well. Your peer’s public key can be hardcoded in the firmware of your TX (predistributed). Or alternatively you can introduce new peers by punching / typing the public key on the keyboard (which is connected to your TX). Note that TX has a unidirectional link to RX, so you can see your own messages you sent.

The full protocol goes like this:

• Alice TX generates $s:= (s_1, s_2)$ at random, uses it to key a symmetric big-key cipher and encrypt message $m$.
• Alice TX sends $c := (\text{pk-enc}(\text{pk-bob}, s_1), \text{big-pk-enc}(\text{pk-bob}, s_2))$ where pk-enc is regular ECIES and big-pk-enc is a big-key public key encryption scheme.
• Bob RX receives and decrypts $s$. Uses $s$ to decrypt $m$.
• When Alice wants to send subsequent messages, she sets $s \leftarrow h(s)$ and uses $s$ to encrypt a new message.

(Gateways omitted in the description above.)

A wrinkle is that you can’t do a full Diffie-Hellman exchange, since there is no bidirectional channel by design. This prevents us from getting the traditional “perfect forward secrecy” properties. We can get slighter weaker post-compromise security by hashing the key material on each message round. Like this, a compromise of endpoint at time N can’t reveal anything about N-1.

(You can still provide some security for future messages if you send on each message material to be added to the shared secret. That only works if the adversary doesn’t get a copy of every message. This assumption is pretty strong.)

Big-key public key encryption. For a concrete scheme, see the accompanying post.

Slow/high domains

In addition to the segregation into RX/TX/GW explained above, there’s a hardware-enforced bandwidth limited channel between keyboard and TX, and between RX and display. The goal here is to restrict to a few bits per second the information that can flow in those links.

We do this to provide exfiltration resistance. We do not speed-limit the unidirectional links TX -> GW, TX -> RX nor GW -> RX. These channels can carry a considerable bandwidth (even though they are unidirectional) since big-key cryptography is expensive (can result in large ciphertexts too).

Unidirectional links consideration

You can’t use ARQ or selective retransmission. We resort to the simplest forward error correcting code: just send the same thing a bunch of times, and hope for the best.

A more elegant solution could be using fountain codes. Keep sending constantly the most recent messages, in case the data link goes temporarily down.

Hardware

I’m prototyping each node with 3 raspberry pis linked with unidirectional serial links. I’m using two UARTs in the raspberry: the hardware one and a soft uart via the kernel module https://github.com/oreparaz/soft_uart.

You can also implement all 3 nodes within a single FPGA. This is left for future work.

The problem

We want to solve discrete logarithm problem in an interval. Our group is an elliptic curve over a 256-bit prime field. The interval size is about 70 bits. This is a problem that has interesting applications (for example, when key generation didn’t use full entropy), but let’s talk about that another time.

The canonical algorithm to solve this is Pollard’s Kangaroo algorithm (extended to distributed search by van Oorschot and Wiener). This takes about $(2+o(1))\sqrt{N}$ group operations. This is an asymptotic measure; but here we want to get concrete and see the concrete cost of breaking (say) a 70-bit discrete log challenge in 2025 USD.

The code

We take a GPU implementation for Pollard’s Kangaroo, with minimal modifications to make it work on different GPU architectures.

The platform

We have the following GPUs available for rent:

The machines are rented from vast.ai, a marketplace for GPU work. GPU owners can rent out GPU time and set a floor bid price. I don’t know much about vast.ai but the experience overall was great: top up $5 and connect 5 minutes later to random machines with big GPUs (some with a residential IP address, yay)

Results

• How many 70-bit logarithms you can get with a $10 budget?
  • Titan Xp: about 4500
  • RTX PRO 6000: about 710. This is a bit surprising, but note that this is 10x more expensive than the Titan Xp.
  • H200: TODO
• How many 64-bit logarithms you can get with $10 budget?
  • Titan Xp: about 13428

Conclusions

• For mid-size problems (around 64-bit problems), older and cheaper GPUs are great. They are pretty efficient and can be optimal for $ / computation (not $ / speed)
• For smaller problems you’re probably better off with just a CPU.
  • A 50-bit problem takes just around 11.5s on an Intel E5-2680 v4 @ 2.40GHz. On a Titan Xp it takes about 17s (203 per hour, or about 41000 for \$10)

eye candy

Example problem for 70-bit ECDLP on an interval:

Start : 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F3297110CEFE6DF0F00AF193D4
Stop  : 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F32971110EFE6DF0F00AF193D3
[1] Priv: 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F3297111067279BA00590DBE69
    Pub: 0364FBFDFF900733243009E571BC503762EC7A809B132D50F2558B2C431E6E4AE0

>>> bin(0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F32971110EFE6DF0F00AF193D3 - 0x8C33238D4C8F2F7FACD4FF3A5BCB73550C7045F3297110CEFE6DF0F00AF193D4 + 1)
'0b10000000000000000000000000000000000000000000000000000000000000000000000'

RTX PRO 6000 drawing 300 Watts:

Titan Xp drawing about 250 Watts:

Log for the Titan Xp:

NVIDIA Titan Xp - 50-bit ECDLP Benchmark Results
Date: Fri Nov  7 06:07:01 PM CET 2025
========================================

Run 1: 21s
Run 2: 17s
Run 3: 17s
Run 4: 18s
Run 5: 17s
Run 6: 18s
Run 7: 17s
Run 8: 17s
Run 9: 18s
Run 10: 17s

All tests completed!
Statistics:
===========
Total runs: 10
Total time: 177s (2m 57s)

Mean time: 17.70s
Median time: 17.0s
Min time: 17s (Runs 2, 3, 5, 7, 8, 10)
Max time: 21s (Run 1)

Sorted times: 17, 17, 17, 17, 17, 17, 18, 18, 18, 21

10 GPU-Hour Throughput Estimate:
=================================
10 GPU-hours = 36,000 seconds
Average time per challenge: 17.70s
Estimated challenges in 10 GPU-hours: ~2,033 challenges

Per hour rate: ~203 challenges/hour
Per day rate (24h): ~4,881 challenges/day

Hardware:
=========
GPU: NVIDIA Titan Xp (Pascal, Compute 6.1)
CPU: 4 threads
CUDA: 8.0
Configuration: GPU Grid(60x256), DP size=9
GPU Throughput: ~565-690 MK/s (typical: ~575 MK/s)


NVIDIA Titan Xp - 64-bit ECDLP Benchmark Results
========================================

Run 1: 40s
Run 2: 51s
Run 3: 43s
Run 4: 74s
Run 5: 79s
Run 6: 46s
Run 7: 65s
Run 8: 43s
Run 9: 66s
Run 10: 40s

All tests completed!

Statistics:
===========
Total runs: 10
Total time: 547s (9m 7s)

Mean time: 54.70s
Median time: 48.5s
Min time: 40s (Runs 1, 10)
Max time: 79s (Run 5)

Sorted times: 40, 40, 43, 43, 46, 51, 65, 66, 74, 79

10 GPU-Hour Throughput Estimate:
=================================
10 GPU-hours = 36,000 seconds
Average time per challenge: 54.70s
Estimated challenges in 10 GPU-hours: ~658 challenges

Per hour rate: ~66 challenges/hour
Per day rate (24h): ~1,584 challenges/day

Hardware:
=========
GPU: NVIDIA Titan Xp (Pascal, Compute 6.1)
CPU: 4 threads
CUDA: 8.0
Configuration: GPU Grid(60x256), DP size=9
GPU Throughput: ~565-690 MK/s (typical: ~575 MK/s)

Log for the RTX PRO 6000:

Statistics:
================================================
Total runs:    10
All solved:    10/10 (100% success rate)
Total time:    758 seconds (12m 38s)

Minimum time:  49 seconds
Maximum time:  126 seconds
Mean time:     75.8 seconds
Median time:   75 seconds

Sorted times: 49, 51, 57, 72, 72, 78, 81, 86, 86, 126

Performance Metrics:
================================================
Average GPU throughput: ~3.9 GK/s
Range searched per run: 2^70 (1,180,591,620,717,411,303,424 keys)
Keys per second (avg):  1.56e+19 (2^64.09)

CPU-only is faster for 50-bit problems, slower for 64-bit problems

  Key Observations:

  1. Huge variance in CPU times: The probabilistic nature of Pollard's Kangaroo shows extreme variance for CPU-only mode:
    - Fastest: 104s
    - Slowest so far: 625s
    - That's a 6x difference between best and worst case!
  2. CPU vs GPU comparison (preliminary):
    - CPU average so far: ~393s (based on first 4 tests)
    - GPU average (from earlier): 54.7s
    - GPU is ~7.2x FASTER than CPU for 64-bit problems ✅
  3. This confirms the break-even point:
    - 50-bit: CPU is 1.54x faster (11.5s vs 17.7s)
    - 64-bit: GPU is 7.2x faster (55s vs ~393s)
    - The crossover happens somewhere between 50-64 bits

Discussion / TODO

• code: there are no modifications to the code for different GPUs. this is probably very suboptimal. experiment with varying parameters
• this is probabilistic. factor success probability
• make an automated discovery of what’s the most economic platform to solve this with the live json bidding from vast.ai
• algorithmic: There are improvements by Galbraith, Pollard and Ruprai that bring the runtime down to $(1.661 + o(1))\sqrt{N}$ https://eprint.iacr.org/2010/617.pdf
• how to rent out your GPUs https://cloud.vast.ai/host/setup

What is in this box? The dongle acts as an interposer: keyboard plugs into one side, computer into the other. It forwards keystrokes transparently, and can cryptographically sign text you type. To the computer, it just looks like a regular USB keyboard. Internally, the dongle has a “secure processor” which holds the signing keys and generates the ed25519 signature.

the twist

So far, all pretty standard. The twist here is that the dongle’s secure processor is isolated by design – it’s airgapped in one direction. The dongle’s secure processor can send data to the computer, but not the other way around. This means the only input the security processor ever sees comes directly from the keyboard – which we assume to be trusted. Malware on the computer can’t talk to it at all. The unidirectional airgap is enforced by means of a “data diode”.

In the demo video you’ll see the message “abc” being signed. You type the message between F5 (start) and F6 (end). The signature gets appended directly after your message, prefixed with psig-. This makes it easy to type directly into emails, chats, or whatever.

Example message:

Hi, hello world from punchsig! psig-1d70ddcfd35e35b78a5a4cbbf7844a7c405c1dac725c7bac48bd7093555cf7130e2a04d563aa0ace0b330c440601524d4c434ad3298ec02e862ef0750eee4c00

security

How the sausage is made. Inside, this thing is made of two processors:

• The red side of things is connected to the keyboard, reads keystrokes, performs signing and forwards them to the blue board over a unidirectional serial link.
• The blue board just receives keystrokes over the serial link and forwards them to a PC. It emulates a USB HID keyboard.

This works differently from a YubiKey. With a YubiKey, the message to be signed comes from the computer — so malware could tamper with it before it’s signed. The user might notice the final message isn’t what they intended, but malware can still batch two signing requests: the real one and a sneaky extra on the side. While YubiKeys can require a user tap for confirmation, it’s easy for malware to fake an error and trick the user into tapping twice.

We go a bit further than the conventional wisdom of “keys are in hardware, they are inextractable”. Hardware dongles don’t live in a vacuum: they must get the input to sign from somewhere. In the majority of the cases, this means getting the input from a host computer. If this host computer is compromised, then malware can sign arbitrary messages. That’s bad. Even if malware can’t access key material, it can sign whatever they want. By forcing the

Are screens enough? One way of dealing with this is putting a screen on the signer. This provides “secure output”. The user is expected to verify what is on the screen vs a trusted reference. There are multiple sharp edges with this: a) how does the user know what a “trusted reference is? b) how is the user expected to be diligent and verify 128 bits (and not be lazy and verify “the few first and few last” bits)?

future

The current implementation of punchsig is a prototype I built in a couple of hours – it does have rough edges and is not suitable for production. Directions for improvement:

• Implement proper key generation. Implement some kind of lightweight “console mode” to print public keys, generate new keys, etc
• Secure boot
• Firmware builds today are reproducibly by means of nix, but they lack documentation
• Implement forward-secure signatures. This would be nice to protect signatures against future compromise. Some scheme based on certs or Krawczyk’s trick would be relatively easy to implement.
• Implement an attestation CA for locally assembled punchsig
• Protect against replays. Today the user can type by themselves a timestamp. It would be great if this is better handled. One option is adding an RTC (but this adds components + a coin cell battery). A GPS module is another alternative.
• Improve reliability of the USB PIO stack. Not all keyboards enumerate yet.

hardware

The two boards are based on Raspberry Pi Pico, connected like this.

code

Firmware is pretty straighforward and largely taken from sample code. There is great code for the raspberry pi pico that implements USB HID host and client. There’s a very simple framing protocol that forwards the HID reports from one board to the other.

Source available at https://github.com/oreparaz/punchsig.

verification

This is the javascript verification page I’ve been using for testing: https://www.reparaz.net/punchsig-verify. Some messages to try:

• Yo, does this thing work? psig-f1424b7587150bb83ac8a895bb4f3424a6228b747083369638d5bfd7f24bd752f1fcbc3a140d431295ecdb163d224c608a0a7d633684a5cc23d1c1791821e30c

• 1, 2, 3, tango! psig-b6291b8c9724429822816e486cda12a690ba861ef7567769d4d24a9f42270941d40e9e4282ac0517bfce033c992a136603f1751ba8c77396a52e3e427fd6b206

• ahem, aham, ahum psig-4ca4a688595e70b1907442c2541a2e11a51257344815acfaf7acde2eb437b06244dfb9b44939520a44a1436c77fc0f3800e4144d9e6a10d29ecd975cf2b4aa06

Parameters:

• All use the ed25519 testing public key 34bc5d83dd91bfa5df1ecada9630e3646fdb497afb4353d7d9f6ba2bb9ac41c0.
• All use the global context punchsig v2025-05-18 context. This is prepended to the message.

build

Some pictures to inspire (or scare) you: the “case” is just a sandwich of styrofoam (terrible thermal properties (but the microcontrollers don’t get hot anyways), provide great physical durability).

There are just two boards that are embedded in the styrofoam:

Connected unidirectionally with 3 wires:

Arnaud Ebalard. x509-parser: a RTE-free X.509 parser. https://github.com/ANSSI-FR/x509-parser

This implements a X.509 parser, with profuse ACSL annotations so that the whole parser is verifiable with frama-c

• This guarantees the parser is free from run-time errors: invalid memory accesses, signed integer overflows, undefined behavior)
• It is suitable for embedded devices (no malloc, no floats, no dependencies)
• The current ACSL annotations cannot prove the code adheres to some specification (correctness) but nevertheless it’s a great piece of engineering
• It is a good resource to learn frama-c and ACSL in a non-trivial project.

This is an excerpt from the paper:

References:

• Arnaud Ebalard, Patricia Mouy, and Ryad Benadjila. Journey to a RTE-free X.509 parser. pretty didactical paper: https://www.sstic.org/media/SSTIC2019/SSTIC-actes/journey-to-a-rte-free-x509-parser/SSTIC2019-Article-journey-to-a-rte-free-x509-parser-ebalard_mouy_benadjila_3cUxSCv.pdf
• Presentation slides: https://www.sstic.org/media/SSTIC2019/SSTIC-actes/journey-to-a-rte-free-x509-parser/SSTIC2019-Slides-journey-to-a-rte-free-x509-parser-ebalard_mouy_benadjila.pdf
• Presentation at SSTIC 2019, with video (in french) https://www.sstic.org/2019/presentation/journey-to-a-rte-free-x509-parser/
• Code: https://github.com/ANSSI-FR/x509-parser

Related:

• Paper: https://iacr.org/submit/files/slides/2023/rwc/rwc2023/46/slides.pdf

Other projects from ANSSI:

• libdrbg (no frama-c verification) https://github.com/ANSSI-FR/libdrbg
• libecc (well engineered) https://github.com/libecc/libecc

The setting is this:

• you run security sensitive meetings with a bunch of participants. say you run those using a laptop over (say) google meet / zoom / whatever.
• you are remote/distributed
• you are concerned about a participant getting pwned and getting replaced by a deep fake
• you can’t change 100% how you operate. you are stuck with google meet / zoom / whatever

The problem:

• you are concerned some participant is getting MITM / phished and replaced by a deep fake

Solution in a nutshell:

• each participant has an iPhone, separate from your corporate laptop
• iPhones are live transcribing what you say + what others say thru the google meet into text
• they encrypt + authenticate this text and send it to a “group chat”
• at the same time, the iphone is monitoring this group chat and detecting whether other iphones are saying in the group chat actually matches its own transcription.
• if they are consistent, the screen of the iPhone is green. If they are not, a deep fake is detected and it should be red and complain loudly

Product notes:

• This is invisible in case everything goes right
• This is loud in case security issues are detected

Implementation details:

• preferably, this is a personal iPhone separate from corporate infrastructure
• all transcription + diarization can happen locally, say with openAI’s whisper models
• iPhones can use secure enclaves for storing keys
• iPhones can communicate out of band
• the transcription match won’t be perfect, we need some sort of “approximate match”
• of course this assumes remote-only attacker that can’t get a hold of these iPhones

Hardware

This is the hardware we’re dealing with. It sells for about $40 on Amazon in the U.S. as of 2019. There are more expensive models from the same manufacturer that have Bluetooth connectivity. Here we are dealing with the simplest model: no Bluetooth, no WiFi, no USB.

PCB

This is a picture of the main board. We can identify some components:

• the main Toshiba processor (IC1 in the picture) is in a LQFP64 package. Markings on the chip: 1904 HAL, T5DE 1UG, 916549. I couldn’t find any datasheet.
• the small IC on the right (IC5) is an 4-kbit I2C EEPROM (markings on the chip: 4G08 82753). This is a 3.3 V EEPROM and behaves like a 24C04.

The I2C bus for the EEPROM is conveniently exposed as two through-holes vias. This is annotated in the picture. It is very easy to solder this bus to your favorite microcontroller. Your extra microcontroller can drive the EEPROM (I2C is a multi-master bus).

High-level behavior

After the unit completes measuring your blood pressure (which takes about a minute), the microcontroller stores the whole measurement into the EEPROM. This is done without any user interaction. The EEPROM memory is large enough to store the last 14 measurements.

EEPROM memory map

This section provides the information necessary to achieve interoperability:

• The EEPROM is 512 bytes long and holds 14 files.
• Each file is 14 bytes long and stores a single measurement.
• The first file starts at offset 0xAC, the second one starts at 0xBA, and so on till the last file that starts at 0x112.
• Each file stores:
  • 1 byte for the systolic pressure, stored as (measured_systolic_mmHg - 25). For example, a systolic pressure of 125 mmHg will be stored as 0x64. (This encoding thus can represent values from 25 mmHg to 280 mmHG.)
  • 1 byte for the diastolic pressure in mmHg units. For example, a diastolic pressure of 80 mmHg will be stored as 0x50.
  • 1 byte for the pulse measurement in BPM “units” (min^-1). For example, a pulse of 53 bpm will be stored as 0x35.
  • 5 bytes that appear to be nearly constant. In my unit these are 0E 20 04 3F 10.
  • 6 more bytes that I don’t understand what they do. The two last look pretty random / uniformly distributed and could be a CRC, although I didn’t dig deeper.
• There are other interesting addresses:
  • Address 0x60 stores the “last measurement file index”. It is a pointer to the measurement that was last written to EEPROM. The mapping “pointer value → file offset” is pretty regular with an exception for the pointer value 0x00:

     mem[addr=0x60] -> file offset
     -----------------------------
     0x01 -> 0xAC (0xAC + 14*0)
     0x02 -> 0xBA (0xAC + 14*1)
     0x03 -> 0xC8 (0xAC + 14*2)
     0x04 -> 0xD6 (0xAC + 14*3)
          ... regular ...
     0x0C -> 0x146 (0xAC + 14*11)
     0x0D -> 0x154 (0xAC + 14*12)
     0x00 -> 0x162 (0xAC + 14*13) // last one, NB: discontinuity!
  

  • Address 0x04 and 0x05 store the total measurement count in little endian. (This is duplicated in addresses 0x06-0x07.) This counter advances even if the measurement is bad. Bad measurements aren’t written to a file.

How to figure this out for yourself. The easiest is to dump the EEPROM contents before and after a measurement and study how the contents change. You can read this EEPROM with any 24C04 driver. I had success with https://github.com/nopnop2002/esp-idf-24c . The Toshiba microcontroller talks to the EEPROM at 320 kbit/s (but of course you can talk to it at a slower bitrate). For example, after a measurement the following EEPROM contents changed:

• the pointer to last measurement (stored at 0x60) advanced from 0x09 to 0x0A
• the file starting at address 0x12A (corresponding to 0x0A) changed
• the first 3 bytes of the file starting at 0x12A are 6f 45 36 which mean:
  • 0x6f: systolic pressure of 0x6f+25 = 136 mmHg
  • 0x45: diastolic pressure of 0x45 = 69 mmHg
  • 0x36: pulse of 54 bpm
• the contents at 0x04 advanced by one (total number of measurements).

Other references. The unit I have has the following markings: MODEL: BP710N, REF HEM-7121-Z. As of 2024 it looks like Omron is selling an updated model BP7100. I don’t know how the BP7100 looks like inside. Chances are that it is very similar.

Warning. You are on your own. Any modification will likely void your warranty. THE INSTRUCTIONS ARE PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE INSTRUCTIONS.

• Part I: protocol for a cryptographic desk clock
• Part II: time reference
• Part II: agreement protocols (this page)
• … sometime in the future … client implementation

Say you have 3 imperfect clock measurements. They do not tell the exact same time. Maybe they are drifting away, or to put things worse maybe one is totally broken. Here we look at this basic problem: given several clock measurements, how do you establish time? We’ll see three fundamental works in fault-tolerant agreement protocols.

Agreement

Establishing a notion of agreement in discrete variables in easy. For example, we can vote to decide where a group should go have dinner (= quorum-based technique). Or we can say we trust certain message when at least a certain threshold of parties trust it (and express this via cryptographic signatures). This works nicely. We can build very robust systems with this approach, a la triple-modular redundancy. Commercial planes land autonomously hundreds of people safely thanks to this.

Establishing agreement in continuous variables is a bit harder. After all, what are outliers? Five-sigma deviation from the mean? Why not \(42 \sigma\)? And how do you take into account the measurement confidence? Or the sensor accuracy?

Never go to sea with two chronometers; take one or three

Marzullo 1983

Keith Marzullo proposed a synchronization algorithm based on interval intersection. Marzullo algorithm provides accurate time synchronization, but does not really deal with faulty clocks. This is the basic idea:

NTP uses Marzullo’s algorithm as inspiration.

Lamport 1987

Leslie Lamport wrote in 1987 the absolutely delightful Synchronizing Time Servers.

The main advantage is that Lamport’s technique can simultaneously deal with faulty clocks and provide similar time to nodes that are relatively close:

Lamport noticed there was something off with Marzullo’s approach. Lamport expresses with astonishing clarity that two nodes that receive a slightly different view of the same clocks may end up with very different end result. This is represented in this picture:

In the context of distributed systems, this is important. You’d expect “close” nodes to have a “similar” view of the time. Technically, this is because the agreement function is not ``Lipschitz continuous’’

The solution Lamport provides is essentially averaging midpoints when the outliers are thrown away. In precise terms:

Drawback: Lamport could not give an “optimal” solution for this. (It is telling the honesty of Lamport, hardly seen in other authors.)

Schmid and Schossmaier 1999

Fast forward, 20 something years later, Schmid and Schossmaier solved Lamport’s concern in their paper How to Reconcile Fault-Tolerant Interval Intersection with the Lipschitz Condition.

They define a very simple agreement function that is Lipschitz continuous, and that takes into account all available information:

This is a comparison of Schmid and Schossmaier vs Lamport function showing Lipschitz continuity in action:

• Part I: protocol for a cryptographic desk clock
• Part II: time reference (this page)
• Part II: agreement protocols
• … sometime in the future … client implementation

Here we will talk about the roughtime time server, and touch a bit on the architecture and security properties. The time reference itself (the time server) is this beauty mess of wires, currently living behind a couch. It has a small cryptographic processor, a GPS and a raspberry pi. This reference propagates the House Standard Time via WiFi.

Server architecture

Time to build! We partition the time server into two clearly distinct blocks:

• trusted domain: comprised of a GPS module plus a small RTOS-based microcontroller. Here we implement the following functionality: parsing GPS module NMEA data, key storage, generate cryptographic signatures

• untrusted domain: a raspberry pi running a golang binary implementing the following functionality: talk to network peers over UDP, construct requests to the trusted domain for signing bundling multiple requests (Merkle tree construction)

  

Why? The whole point of partitioning this way is to minimize attack surface and compact all the security-critical functionality in a small block. This partition is in a sense optimal: the trusted domain does the minimum amount of work needed, minimizing the trusted codebase. All networking code is offloaded to the raspberry (none of which is security critical), all security-sensitive is in the trusted domain. No secrets live in the raspberry. The worst possible impact of a compromised untrusted domain is availability.

The interface between those two blocks looks essentially like this (less important fields omitted):

typedef struct signing_request_t {
  uint8_t merkle_root[32]; // (merkle-)hash of all client nonces
};

typedef struct signing_response_t {
  uint64_t midpoint; // time at the moment of signing
  uint8_t signature[64]; // essentially, signature over merkle_root + midpoint
};

Note that data in signing_request can be 100% attacker controlled — this is fine and actually a scenario we accept. This means the raspi can be 100% popped (the “only” consequence being reduced availability). Time is not chosen by the untrusted domain, the time reference (the GNSS) is directly fed into the trusted domain. The communication between those two domains is a simple serial line, with no framer (yolo), and fixed size packets (difficult, but not impossible, to screw up). The raspi cannot reflash the microcontroller; a human has to plug a programmer to the microcontroller.