A Quiet Afternoon

Filed under: Uncategorized — trinque @ 1:08 a.m.

My brother declared that he'd finish his private pilot's certification before he departs for college. Naturally, keeping me alive in one of these glorified kites was the last test. So here we go!

Below us, Lake Conroe. As wet as it is down there, there's not a body of water in the country that man didn't make himself. Even the "natural" Lake Caddo's had a hell of a lot of human help.

Yes, that bar does keep the wings attached to this piece of shit.

There's nothing up here but nature and man's mark on her. I can see why pilots enjoy it so.

Spot the slave-owner!

Sam Houston

And then we headed back to the airstrip. Who knows what that mess was below, but the sky didn't seem to care.


Towards a Reliable OTP Mechanism for Bot Services

Filed under: Botworks — trinque @ 3:08 p.m.

I have for some time been working on a bot which shall provide a side-channel for small Bitcoin payments, which will rely on the challenge/response mechanism currently employed by the WoT. Key-bearing individuals will be able to create invoices, deposit Bitcoin, transfer to other accounts, and withdraw. Given the risks involved for both the operator and users - and with an evil eye towards the fallen computing industry - I see that such a service cannot be run if the chain of transactions cannot be verified by human hands, and that the whole enterprise must live and die only by those hands.

As we cannot rule out the bastard computers stabbing us in the back, we must watch for the knife. Thus, we require a sequential and immutable log of the challenge/response loop. Separating the challenge/response system - hereafter called the transactor - from the bot, we isolate the information necessary to verify proper operation of the bot. Interactions are of the following form.

There are two machines linked via two one-way and split serial cables: accounting database D (where accounts are represented by keys), and transactor T, which is periodically fed an append-only list of D's known keys and associated nicks through unspecified and manual means. A third machine, logger L, records all communication on either cable.

D receives a request from a user to perform a transaction. D passes request R to T as an ASCII string of the following form, where N and E are the RSA pubkey parameters for the involved parties. R is seen by L as cleartext.

N1 E1 PAY N2 E2 10000000

T replies with encrypted challenge C containing the command requested and an OTP. C is seen by L and D as ciphertext. D relays the ciphertext to the user.

PAY N2 E2 10000000

The user decrypts the ciphertext and returns the cleartext OTP to D, which relays it to T, meanwhile revealing it to L. T replies to D with either "OK" or "FAIL", and a transaction is complete.

In order to trust that T has performed its duties faithfully, the operator must know that OTP did not leak across the serial connection from T to D: not via cleartext, and moreover not via hitching a ride in another encrypted message, by encrypting a message to multiple keys, or insert your own shenanigans here. If a trustworthy log of challenges and responses can be established, the state of the entire system can be checked against the log (for example, at the time of withdrawal, or at some sane interval) and either accepted as a new baseline D state or discarded for the last state verified with L.

Serial printers can be used to reproduce the traffic over the connections between D and T (see thread); however, since verification involves knowledge of the contents of the encrypted challenge, that step requires that the operator decrypt those log items, inspect their contents, and know that they never contained an OTP for another user or any other leaked information. At that point, the time taken to transcribe encrypted challenges to an airgapped verification machine for inspection approaches the confirmation time for a proper Bitcoin transaction. I continue to consider this step of the process, and welcome comments.