Namecoin as Root-CA for .bit-domains/identities

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Namecoin as Root-CA for .bit-domains/identities

Post by renne » Fri Sep 11, 2015 11:14 am

The scandals in the last three years with certificate authorities issuing non-validated certificates and intermediate-certificates or being hacked have shown certificate authorities are not reliable which breaks security of SSL/TLS. CAs do not issue certificates for .bit-domains.

So I suggest to use a blockchain as Root-CA.

How it can work:

Registering name/creating certificates:

1. User uses the Namecoin-client to create and save (e.g. paper-wallet) a Namecoin wallet.
2. User uses the Namecoin-client to register one or more .bit-names/identities per wallet
3. User uses the Namecoin-client to create an X.509 server-certificate (.bit-name) or X.509 S/MIME-certificate (identity) signed with the wallet keys.

Root-CA-lookup:

1.) The Namecoin-client can use an overlay-filesystem to present the tuple <identity|.bit-name>:<public asymmetric key> from the blockchain as virtual X.509-root-certificate files in the SSL root-certificate-directory of the operating system (e.g. /etc/ssl/certs on Linux).

2.) Authentication applications (e.g. TLS/SSL) find the virtual X.509 root-certficates in the filesystem like any other x.509-certificate.

P.S.: I've created a TOR-ticket to use a blockchain to create .onion-domains. Please support the TOR-ticket!

biolizard89
Posts: 1939
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by biolizard89 » Sat Sep 12, 2015 5:45 am

renne wrote:The scandals in the last three years with certificate authorities issuing non-validated certificates and intermediate-certificates or being hacked have shown certificate authorities are not reliable which breaks security of SSL/TLS. CAs do not issue certificates for .bit-domains.

So I suggest to use a blockchain as Root-CA.

How it can work:

Registering name/creating certificates:

1. User uses the Namecoin-client to create and save (e.g. paper-wallet) a Namecoin wallet.
2. User uses the Namecoin-client to register one or more .bit-names/identities per wallet
3. User uses the Namecoin-client to create an X.509 server-certificate (.bit-name) or X.509 S/MIME-certificate (identity) signed with the wallet keys.

Root-CA-lookup:

1.) The Namecoin-client can use an overlay-filesystem to present the tuple <identity|.bit-name>:<public asymmetric key> from the blockchain as virtual X.509-root-certificate files in the SSL root-certificate-directory of the operating system (e.g. /etc/ssl/certs on Linux).

2.) Authentication applications (e.g. TLS/SSL) find the virtual X.509 root-certficates in the filesystem like any other x.509-certificate.

P.S.: I've created a TOR-ticket to use a blockchain to create .onion-domains. Please support the TOR-ticket!
Can you elaborate a bit on how the overlay filesystem would work? Would it require the blockchain to store full certs, or just hashes?

There's some effort ongoing to support Namecoin TLS server certs in Firefox -- Hugo and I did most of the work there. Unfortunately Firefox broke the API we're using starting in Firefox 39. I haven't tested the recent 38 ESR releases; they might still be okay. Iceweasel and TorBrowser use 38 ESR, so might also still be okay. There was some discussion about this on IRC over the past couple days. There are almost certainly ways to generalize this to newer Firefox versions and to other browsers, but they're generally unpleasantly hacky.

I also looked at using TLS client certs for identity login. I think it might be pretty easy to do this for things like Drupal, which already support client certs. Then the question becomes, how do we deal with multifactor authentication? Daniel's NameID design is in theory extendable to do multifactor auth, while TLS doesn't have a natural way of doing it. Suggestions would be welcome.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Sat Sep 12, 2015 9:32 am

biolizard89 wrote:Can you elaborate a bit on how the overlay filesystem would work? Would it require the blockchain to store full certs, or just hashes?
Neither! ;)
A Namecoin process on every every host would scan the complete blockchain at first start and generate a root certificate for each wallet with valid names/identities in the local certificate storage. Afterwards it would update the certificates when names/identities are added/removed in the blockchain. The process would only use already existing information in the blockchain to create a root certificate (<name.bit|identity> -> CommonName, timestamps, ...).

The basic solution would be to have the process create real certificate files in the local certificate storage of each host. The drawback would be to have to scan the certificate storage on each start of the process for old invalid certificates. Using a Virtual Filesystem like FUSE allows to create certificates on the fly. Have a look at the hello world-example.
biolizard89 wrote: There's some effort ongoing to support Namecoin TLS server certs in Firefox -- Hugo and I did most of the work there. Unfortunately Firefox broke the API we're using starting in Firefox 39. I haven't tested the recent 38 ESR releases; they might still be okay. Iceweasel and TorBrowser use 38 ESR, so might also still be okay. There was some discussion about this on IRC over the past couple days. There are almost certainly ways to generalize this to newer Firefox versions and to other browsers, but they're generally unpleasantly hacky.
I suggest to use JavaScript to create client-certificates instead of a Firefox add-on or plug-in. I've uploaded a proof-of-concept I once made for client-certificate hashes stored in a blockchain. Alternate names and direct import into the browser don't work, yet. But it creates a X.509 client-certificate in Firefox. You need to compile forge.min.js with node.js.
biolizard89 wrote:Suggestions would be welcome.
Do we really need multi-factor authentication with password-protected client-certificates?

biolizard89
Posts: 1939
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by biolizard89 » Sun Sep 13, 2015 1:26 am

Sounds pretty cool. I'm a little bit distracted today, but a few quick questions:

Can a virtual filesystem be used with non-Linux OS's, particularly Windows? What about systems that use NSS (e.g. Firefox, and Linux Chromium)? Can this work with SPV-based Namecoin clients that only download name data on demand? Is this design able to restrict the set of accepted certs, or just expand it? (In other words, will it prevent a malicious ICANN CA from issuing a Namecoin cert?)

I'd love to see some more details/documentation on this.

Cheers!
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Sun Sep 13, 2015 9:55 am

biolizard89 wrote:Can a virtual filesystem be used with non-Linux OS's, particularly Windows?
Citation of Wikipedia:

Code: Select all

This implementation of FUSE is available for Linux, FreeBSD, NetBSD (as puffs), DragonFly BSD (as puffs), OpenSolaris, Minix 3, Android and OS X.
https://github.com/dokan-dev/dokany seems to be a similar solution on windows. Alternatively a WebDAV-server could be implemented which provides the blockchain information as files in a WebDAV-share mounted into the certificate store.
biolizard89 wrote:What about systems that use NSS (e.g. Firefox, and Linux Chromium)?
As long as the NSS libraries can accesse the systems certificate store it would work.
biolizard89 wrote:Can this work with SPV-based Namecoin clients that only download name data on demand?
Virtual files of virtual filesystems never really exist on any storage device. The VFS just intercepts and manipulates the readDir, open, read, write and close calls and returns the data you want. ;) That way you can represent any data as files-on-the-fly. For creation of virtual files a list of all valid CommonNames (d/<name>, id/name) would be necessary. The public key can be fetched on demand.
biolizard89 wrote:Is this design able to restrict the set of accepted certs, or just expand it? (In other words, will it prevent a malicious ICANN CA from issuing a Namecoin cert?)
If blockchain CA-root-certificates and conventional CA-root-certificates are in the same certificate-store they can't be distinguished by applications. The only way I see is a process which scans for malicious certificates and deletes them (if CommonName ~= *.bit AND NOT in Namecoin-subdirectory -> delete).
biolizard89 wrote:I'd love to see some more details/documentation on this.
Let's take the "Hello World!"-example of FUSE:

Code: Select all

static int hello_getattr(const char *path, struct stat *stbuf) {}
would always set read-only attributes (0555/0444) for directories/files in the virtual filesystem to avoid malware storing bogus certificates.

Code: Select all

hello_readdir(const char *path, void *buf, fuse_fill_dir_t filler, off_t offset, struct fuse_file_info *fi){}
would create a directory structure with filenames like "<name>.crt" by adding all valid <names>.

Code: Select all

static int hello_open(const char *path, struct fuse_file_info *fi){}
would parse the <name> from *path and check if the <name> exists.

Code: Select all

static int hello_read(const char *path, char *buf, size_t size, off_t offset, struct fuse_file_info *fi){}
would parse the <name> from *path, request the corresponding public key from the blockchain, create an unsigned CA-root-certificate and return it via *buf.

X.509-applications don't seem to scan for specific directory-/filenames but scan ALL files which would break every system with 10 billion virtual certificate files in the certificate store. I'm already looking for a solution (configuration option, API, ...).

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Sun Sep 13, 2015 10:44 am

A clean solution would be to extend Namecoind as a Server-Based Certificate Validation Protocol (SCVP) server. Unfortunately current SSL/TLS-libraries/-applications like OpenSSL don't support SCVP, yet. It would be good for a proof-of-concept implemetation of the blockchain<->X.509-combo as an authentication-system but would not allow a productive deployment at this time.

biolizard89
Posts: 1939
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by biolizard89 » Mon Sep 14, 2015 8:09 am

renne wrote:X.509-applications don't seem to scan for specific directory-/filenames but scan ALL files which would break every system with 10 billion virtual certificate files in the certificate store. I'm already looking for a solution (configuration option, API, ...).
Shouldn't be too hard to hook the domain lookup (or some other event that occurs before the TLS handshake), so that only .bit domains that were looked up in the past 10 minutes have visible certificate files. Assuming, of course, that the TLS validation library loads the certificates from the filesystem after that hook occurs.

I kind of dislike this approach because it still trusts ICANN CA's not to sign .bit certs. But, as Ryan said on GitHub, all available solutions are going to suck in some way, and it's our job to find a method or combination of methods which suck as little as possible.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Mon Sep 14, 2015 11:16 am

biolizard89 wrote:Shouldn't be too hard to hook the domain lookup (or some other event that occurs before the TLS handshake), so that only .bit domains that were looked up in the past 10 minutes have visible certificate files. Assuming, of course, that the TLS validation library loads the certificates from the filesystem after that hook occurs.
I haven't found any documentation for e.g. OpenSSL how certificate-files are loaded/parsed from the certificate-store. It seems OpenSSL just parses all certificate-files and stores the information somehow in RAM or a temporary file. If so, there wouldn't be any way to predict which CommonName is next.

If you're going to patch X.509-/SSL-libraries, it would be simple.

1. When you create a server- or S/MIME-certitificate, use e.g. the string "Namecoin" as identifier of the certficate-authority, the <name> of the wallet as CommonName and the private key of the wallet as CA-root-certificate private key to sign the server- or S/MIME-certitificate.

2. If the X.509-/SSL-libraries have validated the server- or S/MIME-certitificate itself (timestamps, etc.) and find the string "Namecoin" as identifier of the certficate-authority they can just fetch the public key of a wallet by CommonName/<name> via Namecoind and validate the signature with the public key of the wallet.
biolizard89 wrote:I kind of dislike this approach because it still trusts ICANN CA's not to sign .bit certs. But, as Ryan said on GitHub, all available solutions are going to suck in some way, and it's our job to find a method or combination of methods which suck as little as possible.
As long as X.509-/SSL-libraries trust ICANN, the only way is some kind of filter which suppresses bogus certificates for .bit.

The cleanest way would still be to add a HTTP-based SCVP-API to Namecoind and encourage developers/vendors of X.509-/SSL-libraries to outsource validation to a SCVP-server (->Namecoind).

P.S.: Is there any way to run Namecoind and Namecoin-QT in parallel on the same local blockchain-store/wallet? Namecoin-QT doesn't seem to have a HTTPS-API which I could use for my experiments.

biolizard89
Posts: 1939
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by biolizard89 » Mon Sep 14, 2015 7:35 pm

Namecoin-Qt should open an RPC port as long as "server=1" is set in namecoin.conf. Note that Namecoin Core 0.12 and higher will use cookie authentication unless you explicitly set a username and password in namecoin.conf; older versions will notify you if the username and password are missing.

So, going back to your suggestion of generating a certificate from just a public key in the blockchain... it would be interesting if we had a deterministic algorithm for doing this which all .bit sites could use. In particular, there appears to be a Firefox extension API which can import certificates into the certDB, given a base64 encoding of the certificate. (This API will disappear when XPCOM disappears in 2016-2017, but we can use it until then.) I might play around with this a bit....
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Mon Sep 14, 2015 8:36 pm

biolizard89 wrote:Namecoin-Qt should open an RPC port as long as "server=1" is set in namecoin.conf.
"server=1" did the trick. ;)
biolizard89 wrote:So, going back to your suggestion of generating a certificate from just a public key in the blockchain... it would be interesting if we had a deterministic algorithm for doing this which all .bit sites could use. In particular, there appears to be a Firefox extension API which can import certificates into the certDB, given a base64 encoding of the certificate. (This API will disappear when XPCOM disappears in 2016-2017, but we can use it until then.) I might play around with this a bit....
In which format is the private key returned by "dumpprivkey" encoded?

Post Reply