Subject: Re: [6tisch] questions about draft-richardson-security-6top

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Jul 2015 20:51:42 -0400

Malisa Vucinic <[email-masked]> wrote:
    > [the rest of the discussion shifted to [6tisch] joining security start
    > and end states]

hi, sorry to take so long to reply.... I'm sure you have the same experience
of putting off the most important emails, because they deserve a well thought
out response...  

    > On 13 May 2015, at 09:43, Michael Richardson <[email-masked]> wrote:
    >> So, here, I think you are imagining using some kind of pre-provisioned
    >> session-resumption ticket to replace the initial TLS handshake.  I
    >> think that this is something that one could imagine: the initial TLS
    >> handshake is done at the factory, and then, based upon a bearer token,
    >> the factories' MASAS (see
    >> draft-pritikin-anima-bootstrapping-keyinfra-01) might return that.  Is
    >> this what you are thinking about?

    > So this would be a clean way of doing what I had in mind. I guess an
    > obvious concern in this case would be how the initial TLS handshake can
    > be done at the factory during mass production in a scalable manner.

I think it depends a lot on what part of the "factory" you are in.
How do factories' load "Manufacturer Installed Certificates" (often called:
MIC. Too confusing a term. We need another TLA for this) now?  If my
manufacturing process included a "bed-of-nails" test, then I might do it
at that point via JTAG, otherwise, doing it via JTAG during or after the QA
process seems like the best way to me.  Being able to have the device
zerotouch boot the first time might be a major win for the QA process too.

    > I was thinking more of something like this:

    > Consider the joining node JN_1 which was imprinted with symmetric key
    > K_1. MASA keeps track which JNs were imprinted with which keys. MASA
    > and all of its nodes use the recommended ticket format from Section 4
    > of RFC 5077. Nodes get shipped, deployed.

    > 1. JN_1 initiates the join process with the local network, sends its
    > IDevID via JA to the JCE.

    > 2. JCE asks MASA about JN_1 over https. MASA’s factory sold the nodes
    > to the owner of JCE so MASA already knows that JCE is the rightful
    > owner of JN_1.

    > 3. Then, MASA can generate 48 random bytes to be used as the master
    > secret for session between JCE and JN_1. Obviously, MASA is a trusted
    > third party. MASA generates the rest of the ticket, using as key_name
    > the fingerprint of K_1 and also includes the cipher suite knowing what
    > ciphers JN_1 supports, as it manufactured it after all. MASA encrypts
    > the ticket using K_1.

    > 4. MASA sends to the JCE the encrypted ticket and the plaintext version
    > of it (this is what an RFC 5077 client possesses anyways, it does
    > however not know K_1).

    > 5. JCE can now start the abbreviated handshake with JN_1, including the
    > encrypted ticket in ClientHello.

    > 6. JN_1 decrypts the ticket using K_1, takes the session state from the
    > ticket as normally done in RFC 5077 and verifies that it supports the
    > cipher. Then it can continue the abbreviated handshake with JCE.

This would all work well.  The 5077/Section 4 format does not include any
information about the end point identifiers, so that's fine.  All in all,
it's very Kerberos-like.

    > If MASA decides to share K_1 with JCE, JCE can also generate the
    > session ticket without any involvement of MASA. All in all, by making
    > an assumption on out-of-band exchange of supported ciphers and MASA as
    > a trusted third party, I think one could get the DTLS handshake done in
    > 4-6, instead of 10-12 packets. Does that make sense and do you think it
    > is worth the trouble?

One can go further, and provide K_1 in the form of a QR code with the device.
Or one can provide a bearer token in the QR code, which when provided to the
MASA, convinces the MASA to either hand over K_1, or as you suggested, hand
over the session resumption ticket.

My understanding of Quantum Cryptography is not great; but I what I
understand is that asymmetric algorithms (RSA, ECDSA) are more susectible.
As K_1 would be the key to a symmetric algorithm, it might be less vulnerable
over a long (~20 year) time frame between the device being manufacturered,
being warehoused, and then deployed.

A concern with 1/2 is that the device does not have to prove it (still)
possesses the private part of the IDevID.  Instead, K_1 has replaced that.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Malisa Vucinic <[email-masked]>
Date: Tue, 28 Jul 2015 17:18:20 +0200

> On 26 Jul 2015, at 02:51, Michael Richardson <[email-masked]> wrote:
> 
> out response…  

Stay tuned, here is another long one :-). 

> over the session resumption ticket.

Yes, I suppose the bearer token would make part of the JCE-MASA exchange. It seems that from JN’s perspective, it doesn’t matter what sort of handshake is initiated by JCE, as long as K_1 is signaled as the PSK to be used and the JN plays the DTLS server role.

> being warehoused, and then deployed.

We will have to rethink quite some stuff when that day comes :-). 

> possesses the private part of the IDevID.  Instead, K_1 has replaced that.

What I meant with ‘IDevID' in my previous mail was an identifier with no crypto binding. That made me think about the start/end state discussion and how to protect that initial communication from JN to JCE.

Consider for instance the case with symmetric keys *only* and EUI-64 instead of the IDevID certificate. The JN could use K_1 to protect its EUI-64 when it first contacts the JA. JCE would not respond, i.e. initiate the DTLS handshake, if that check fails once K_1 is obtained from MASA. Goal is to remove the risk of initiating a DTLS handshake over multiple hops with a rogue JN. 

To avoid replay, JN can simply include the freshly learned ASN in the protected message containing its EUI-64.

Something like:

1. JN -> JA: { EUI-64, ASN }, integrity protected with K_1

2. JA -> JCE: // JA forwards JN’s message

3. JCE either: 1) already possesses K_1 corresponding to JN’s EUI-64; 2) obtains K_1 from MASA using the bearer token you mentioned that is physically imprinted on JN; 3) forwards JN’s message to MASA and expects MASA to verify it and pass the session resumption ticket in which case step 4 is omitted.

4. JCE verifies the MAC of { EUI-64, ASN }   // JCE should have a window what ASN to expect

5. JCE initiates the DTLS handshake with JN using 1) K_1 signaled in the PSK hint; 2) using session ticket from MASA encrypted with K_1

With asymmetric crypto and Manufacturer Installed Certificates, I think we can have a similar flow. In Step 1, we could replace EUI-64 with IDevID and usage of K_1 with the corresponding private key. On one hand, as IDevID can probably be obtained from MASA or some other web database, it could be beneficial to avoid the transmission of the full certificate and instead just communicate the unique identifier, such that the certificate can be looked up by JCE. On the other hand, JN can transmit IDevID to the JA such that JA can immediately verify the message received in Step 1 before forwarding it upwards. (Verification at JA assumes that JA already trusts JN’s Certificate Authority.) 

Steps 3, 4, 5 would then equivalent to signature verification and asymmetric DTLS handshake. 

Would that make sense? One concern I see is an attack on JN forcing Step 1 over and over to compromise K_1 once the nonce wraps around. As long as K_1 is not a group key I don’t see a benefit of doing this since JN is already in physical possession of the attacker for the attack to be launched. 

Mališa