Cryptography Mailing List 2023

 

SafeWebdrop
An encrypted message exchange mechanism for the CryptoBone

Dear List, I'd like to present SafeWebdrop, an encrypted message exchange mechanism for the CryptoBone, for constructive criticism. Apologies for the long posting. As we all know [1] the CryptoBone [2] simplifies the key management for users who wish to exchange always-encrypted messages but does not make any attempt to disguise the fact, that a message exchange has taken place, because the default transport mechanism is EMAIL. Today, with multi-factor authentication and similar shenanigans (spam control, etc) it becomes increasingly difficult to establish reliable EMAIL exchanges using standard programs on dialup devices like laptops. Because a simple exchange of encrypted messages does not really need an ISP hosted email account, a different HTTPS-based exchange mechanism is desirable. The basic idea behind SafeWebdrop is, that people wishing to communicate securely may have contact to a webserver administrator (think of a community or organization, ...) who can be convinced to add a minimalistic software to a server, which already provides HTTPS for other reasons (LetsEncrypt, etc.). With the installation of three bash-scripts the server admin can establish a direct message exchange service [3], that does not interfere with the official use of the server. SafeWebdrop requires the attention of the admin only once, when a user's public key is accepted and stored in the users safewebdrop directory (account registration). Everything else works without the admin's involvement. Given, that a webserver admin can be found to extend their service for users, who can be contacted first hand, SafeWebdrop is minimal invasive. So here are the three mechanisms for scrutiny in detail. Message exchanges between a user's device and the server rely on HTTPS, already present on the server. That means, one side of the SafeWebdrop service is authenticated and encrypted (in the sense in which for instance an online bank is authenticated). What's missing is the authentication of the user-side. SSH would be the ideal solution for this part, but I do not want to burden the server administrator with the task of establishing all SafeWebdrop users as real users on the server. Minimal invasiveness means that an additional user is simply a directory with a RSA public key in it, nothing more. The only precondition to start a secure communication between two people is the exchange of a random 20 character initial secret, preferably exchanged in person on a piece of paper. There are three protocols, I use the notation similar to Ross Anderson's [4] Account Registration: --------------------- A : User Alice S : Server <https> A -> S : UID, registration S -> A : hash(Nonce) # S stores IP, UID and Nonce A -> S : UID, {UID, hash(nonce)} RSAprivA, RSApubkeyA # S checks IP, challenge and UID # S verifies signature and stores Pubkey # and RegCode in a directory UID S -> A : RegCode # RegCode is 22 char random hex </https> The registration code stored on the server must be handed over by the person, who wishes to use a new SafeWebdrop account, directly to the server administrator. The admin checks that the registration code matches the one on the server and copies the RSA public key into the directory created for the user. The admin's involvement stops here. Of course, anyone can register a given UID. But if the UID is not in use already, providing the RegCode offline guarantees that the legitimate Pubkey, the one generated by the CryptoBone system, will be stored in the new UID directory. Any attempt to use this account will require the use of the corresponding RSA private key. Reading SafeWebdrop Messages: (authenticated pull) ----------------------------- <https> A -> S : UID, NEW # server checks that UID exists and # has a public key S -> A : hash(Nonce) # S uses a new stored Nonce A -> S : UID, {UID, hash(Nonce), GET} RSAprivA # S performs the checks as in registration # S concatenates all safewebdrop messages # generates a hash and a list and sends S -> A : allsafewebdropmessages A -> S : UID, {UID, hash(Nonce), hash(allmess.)} RSAprivA # S performs checks and verifies hash # S deletes all safewebdrop messages S -> A : OK </https> Sending SafeWebdrop Messages: (push a message) ----------------------------- CASE 1) unauthorized: B : any user <https> B -> S: A, B, b64(message) # S checks that A exists # S checks that message is in AES encrypted # openPGP message format # S stores message in A's directory S -> B: OK </https> CASE 2) authorized user on the same server S: C : User that is registered on S <https> C -> S: A, C, {C, b64(message)} RSAprivC # S verifies C's signature and proceeds # as in CASE 1 S -> C: OK </https> CASE 3) authorized user on another server S2: D : registered on S2 and exchanged an initial secret (sec) with A A%S is Alices full safewebdrop address <https> A -> S: A, {D%S2, hash(A%S, D%S2, sec)} RSAprivA # A tells S, that if D%S2 sends a # public key and this hash, D%S2 is # allowed to send safe webdrop messages. D -> S: A, D, {hash(A%S, D%S2, sec)} RSAprivD, RSApubkeyD # this is done by the CryptoBone, when D # enters the secret sec for A into the # GUI # D%S2's pubkey is saved in A's directory # S can verify that A allows D's pubkey # to be used to check D%S2's messages D -> S: A, D, {D, b64(message)} RSAprivD # S can verify D's signature, as it finds # D's pubkey in A's contact subdirectory # the server admin is not involved to # authorize D on A. # S stores D's message for A. S -> D: OK </https> It will be the sole administrator's choice whether he accepts unauthorized messages. The essential part is the authorization of D on S based on the initial secret that had been exchanged between A and D first hand. Any objections? Any (obvious) improvements? --ralf [1] https://www.metzdowd.com/pipermail/cryptography/2015-January/024194.html [2] https://crypto-bone.com [3] https://safewebdrop.com [4] Ross Anderson: Security Engineering, Chapter 2 (Protocols)