Re: [homenet] HNCP Security & Trust Draft

[Steven Barth <[e-mail]>]

Hi Mikael,

thanks for your feedback.


> Being a crypto novice, let me write some text and please tell me if it 
> makes sense in the context of your draft (thanks for writing it, it 
> looks like a good summary).
I do not consider myself to be a crypto expert either which is one of 
the reasons I'd try to offload the actual crypto to something 
well-known. Also this probably means that what I drafted might not be  
100% accurate but I hope some of the actual expert will review it.


>
> I like SSH. SSH generates its own public/private key, there are 
> fingerprints I can put in SSHFP DNSSEC secured posts, etc. Are the 
> public/private keys considered to be similar to self-signed 
> "certificates"?
I'll answer this in the context of the consensus based trust-scheme I 
added in addition to the PSK and PKI-based trust scheme. Yes, using 
self-signed certs here is possible since it's simply X.509.


>
> Anyhow, let me propose a scenario:
>
> I get my first homenet router and power it up. It comes with a QR code 
> on it, and it has a button (or NFC, similar principle). I scan the QR 
> code on my smartphone (with a special homenet-control-app) which gives 
> it enough information to connect to the wifi of the router, then I am 
> asked to press a button on the router to allow my phone to become the 
> administration device. The QR code contains wifi information and key 
> fingerprint ID so my phone can decide that it's speaking to the 
> correct device.
Right that would be possible and the QR-code would be an additional 
"trust bootstrap ceremony" in that context. I actually had a phone / 
homenet-app scenario in mind when drafting this. So I was thinking about 
two possible cases.

Case #1: The app is bound to the router itself via some kind of 
vendor-specific RPC so it can control its configuration directly. That 
RPC allows the app to read / receive fingerprints and names when a new 
device attempts to join the homenet and allows the user to give a 
verdict (trusted / untrusted) which is then announced by the router 
itself and not the phone.

Case #1 is pretty obvious because it isn't really problematic and not 
bound to the phone itself and you could probably do the using some kind 
of webinterface on such a router.

Case #2: The app itself speaks HNCP, i.e. the base state synchronization 
part (not the routing, addressing, SD whatever). It is standalone (i.e. 
doesn't depend on a specific router, just has to peered with any HNCP 
router once so it is trusted) from then on it can itself announce trust 
verdicts about other routers.

>
> Now, after this, my phone app can speak to the router, and when I hook 
> up another device to that router, it detects the new device, 
> fingerprint ID etc, and asks me before it's allowed. After I ACK that 
> it's allowed to talk to my homenet (which previously only consisted of 
> a single router), they exchange session keys (or something) for 
> management, so they can continue to talk.
In Case #1 above it could tell the router to announce a trust verdict 
(trusted / untrusted) or in Case #2 it would do so by itself.

The session key exchange would then be done by the underlying protocol 
i.e. DTLS, IPsec/IKE, ...
The only real addition here should be that this underlying protocol (or 
its implementation) needs to allow a custom verification hook (i.e. 
notifies the HNCP daemon that there is a an unknown certificate and 
allows it to be accepted or not). For DTLS e.g. this shouldn't be 
problematic since most libraries seem to support such a callback.


> Just like with SSH allowing key based login, the management of homenet 
> devices would rely on the public key for each accepted device being 
> known to all the other devices, and this is how things authenticate. 
> This would be the "anchor" that everything else relies on when it 
> comes to security.
Yes, each device would announce the fingerprints of the certificates or 
public keys (details TBD) that it trusts in its HNCP-state.

>
> Now, the problem is what to do when I lose my phone and don't have any 
> backup, so perhaps I need a user/password based login to add new 
> administration devices, it seems hard to work around.
Each device may announce verdicts about public keys / certificates and 
verdicts of device which are absent are cached by other HNCP routers so 
your case and Case #2 above would work without the app/phone always 
being there.

>
> If someone gets the private key of any of the accepted homenet 
> devices, of course everything falls down, but I don't see any way 
> around it apart from having TPM etc.
Yeah that's also the downside here. It's even more apparent if anyone 
can say someone else is trusted or not. But I guess ultimately its the 
same issue and once you are actually a trusted homenet router you can do 
more nasty things like messing with routing etc. than actually attacking 
the trust system itself, especially since most of the algorithms / 
applications run over HNCP are distributed / consensus based anyway.


Cheers,

Steven