[tor-talk] A Tor-based Public-Key Infrastructure

[Rene Bartsch]

Great idea!

To avoid the dependency on servers/providers I suggest to take a 
Bitcoin-like blockchain with an extension to assign self-registered, 
globally unique pseudonyms to blockchain wallets and use the private 
ECDSA-key of the blockchain wallet corresponding to the pseudonym to 
sign X.509 certificates (e.g. S/MIME, object-code-signing, intermediate 
certificates for server applications like TLS, ...) which use the 
self-registered, globally unique pseudonym of the blockchain wallet as 
CommonName.

https://wiki.namecoin.info/index.php?title=Identity already provides a 
blockchain with registration of pseudonyms (=identity). All you need to 
do is the following:

Alice:
1. uses namecoind/Namecoin-QT to create a Namecoin blockchain wallet
2. uses namecoind/Namecoin-QT to register a pseudonym in 
Namecoin-blockchain (= identity)
3. uses some kind of application (e.g. HTML5 offline-app connecting to 
namecoind-/Namecoin-QT-RPC-API) which
    1. retrieves the private ECDSA-key key from the wallet
    2. calculates the public ECDSA-key to retrieve the matching identiy 
from the blockchain
    3. creates a x.509 certificate signed with the private ECDSA-key of 
the blockchain wallet (identity = CommonName)
    4. offers to save the x.509 certificate
    5. imports the x.509 certificate into the browser if applicable (e.g. 
for TLS client authorisation)
4. installs saved x.509 certificate into any other application used for 
communication
5. retrives Bob's public key from blockain
6. connects to Bob providing her own x.509 certificate and validating 
the x.509 certificate presented by Bob

Bob:
1. same as Alice
2. same as Alice
3. same as Alice
4. same as Alice
5. accepts connection request from Alice
6. retrives Alice's public ECDSA-key from blockain and validates Alice's 
X.509 certificate



Advantages:
1. Tamper-proof publication of CommonName (=identity) <-> public 
key-tuple
2. Alice's applications (E-Mail, TLS, ...) already support x.509 
certificates, so nothing to patch
3. Bob's applications can be patched easily by adding libcoin-support or 
namecoind-RPC-support

Disadvantages:
1. Namecoin stores a lot of meta-data in blockchain -> traffic and 
storage overhead
2. monetary operations -> small costs of money
3. Namecoin identities are lost if not renewed within 36000 blocks (~ 5 
months)


I suggest to use the Namecoin blockchain as proof-of-concept and start a 
IETF workgroup for the real-world implementation.




Am 2016-01-11 23:59, schrieb Ethan White:
> First off, this is my first post to tor-talk, so I'm not even really
> sure this is the right place, but...
> 
> Recently, I've been toying with an idea inspired by a posting on
> tor-talk by Mike Perry from September 2013 [1], in which alternatives
> were discussed to Web of Trust (WoT); specifically, the suggestion
> “Every time GPG downloads a new key, re-download it several times via
> multiple Tor circuits to ensure you always get the same key.”
> 
> I've developed it more, and I've come up with a comprehensive
> public-key infrastructure that associates e-mail addresses with
> arbitrary data (such as public keys). We assume Alice is using the
> e-mail address alice at alice.com, and Bob is using the e-mail address
> bob at bob.com. Alice wants to get Bob's public key securely. My goal
> with this is slightly different from most PKIs: I simply want either
> Alice or Bob to notice if anything fishy is going on. They can then
> simply publish broadly that something is off. (This would be a nice
> thing to eliminate; if anyone has any ideas, feel free to suggest
> them).
> 
> The obvious solution is to have Bob upload his public key to bob.com,
> and then Alice can simply use the three-tor-circuit method to download
> Bob's public key. However, this has the flaw of trusting bob.com;
> bob.com could simply serve up the wrong public key.
> 
> To solve this, Bob could periodically check that bob.com is serving up
> the right public key. The intervals would have to be random, since Eve
> could simply MITM everyone and serve up the wrong public key except
> when she knows Bob usually asks.
> 
> However, this still has a problem: let's say Bob is a high-value
> target like a journalist, and Eve is, for example, an intelligence
> agency. Eve could simply sit outside Bob's house, and, whenever she
> sees a packet into the Tor network, not MITM anyone for a few seconds.
> Thus, Bob's illusion that his public key is being served up
> authentically is maintained, but yet Eve can still MITM Alice (or
> anyone else). This doesn't even seem too far-fetched; this is what
> NSA's QUANTUM injection is, is it not?
> 
> To solve this, Bob would send some sort of traffic to the first relay
> every (average latency of the tor network) / 2 seconds, which would
> almost always be something meaningless (like a TLS warning message),
> except occasionally when it's actually a request to bob.com to grab
> the public key.
> 
> I have a few questions:
> * Do I actually have to worry about QUANTUM-style attacks?
> * Are there any vulnerabilities that I'm missing?
> * Is this practical? Would it effecively DDOS the Tor network?
> * Could I do this in any way that doesn't rely on DNS?

-- 
Best regards,

Rene Bartsch, B. Sc. Informatics