> On 26 Jul 2015, at 02:51, Michael Richardson <[email protected]> wrote:
>
> 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…
Stay tuned, here is another long one :-).
> 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.
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.
>
> 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.
We will have to rethink quite some stuff when that day comes :-).
> 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.
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
