Subject: [Roll] review of draft-dvir-roll-security-extensions-00.txt

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Mar 2011 13:54:31 -0400

I read this document in January, and the authors and I had a short VoIP
chat about it.   I promised to post my thoughts, but life has
intervened.  

My first comment is that this is two documents:
      3.1  DIO Message Authentication  . . . . . . . . . . . . . . . . 5
      3.2  Local Key Agreement . . . . . . . . . . . . . . . . . . .  13

I believe that it should be split up into two documents.

To first order, 3.1 DIO Message Authentication is a problem statement,
it details a limitation in the security model that we have assumed, and
then presents a short solution.  I'd like to see the threat more clearly
outlined.

3.2 Local Key Agreement is a solution to a slightly different problem,
and there is some cryptography there which I did not pay enough
attention to, in great part because I want to make sure that we know
what problem we are trying to solve, and I do not think that 3.1 is
solveable with JUST per-peer authentication keys.  Creating per-peer
authentication keys significantly mitigates some attacks that, but I'm
not actually sure which attacks it defends against, because we do not
yet have a clear risk assessment of what nodes within a pre-installed or
authenticated network can do if they decide to be malicious.

(I would have liked to see this analysis in the Security Considerations
section of the main RPL document, but I agreed that it could be out of
scope for the base spec, which assumes all nodes are trusted)

In particular, there is an assumption that for some class of devices it
will be possible to to subvert individual devices in some small bounded
amount of time (I'm guessing hours to small number of days), and
retrieve the important RPL parameters (the RPL pre-installed keys,
or the layer-2 security keys) such that fake messages can either be sent
out by a rogue node, or that the subverted node can be forced to become
a trojan.

I'd like to see this assumption made more clear: what are the real
attack methods for closed networks operated by a single entity?

I do not think, however that this attack being unimportant for many use
cases invalidates this work: I am interesting in more open networks (I
think that many home networks will be such) where it is impractical to
use layer-2 security, and we will rely upon layer-3 RPL security with a
combination of unsecured networks with an enrolled system that gets
visitors to your home into the pre-installed state.  The devices that
such visitors bring will only be partially trusted, and will generally
be running on untrustworthy devices.

To that end, I'm going to actually ignore the bulk of the document as
technical details, and focus just on 3.1.

Section 3.1 worries about what happens if some node in a DODAG 
(why does it matter if it's grounded?) starts to send out messages with
a malicious intent to disrupt traffic.

In The RPL base spec, we assume that nodes are either in the DODAG, or
they are not.  I'm going to ignore the leaf/router node for now, because we
can not yet make this work without assymetric encryption.

Section 3.1 is about protecting some critical information using a hash
and does not require assymetric encryption.  There is a problem with how
do nodes bootstrap into getting an authentic h^n(r), and the document
punts slightly by suggesting that a digital signature be used. It
assumes that we can amortize the cust of verifying this digital
signature over n-Version increments.  

How often do version numbers increase, 
vs how costly is a signature verification, 
vs how big can we make n?

The above are questions that need to be researched, and the answers
detailed in applicability statements for different RPL usage.

I do not believe that any of our existing MAC functions work because
in effect, every node that has the symmetric key preshared key K
can send such messages, and we are really back to square one: all nodes
are equally trusted.

Now, at this point we have authenticated the DIO message.
My question is, what other things would be worth authenticating in this
fashion?   

How much more can we do using mechanisms like the one presented in
section 3.1?  I'm thinking about if it becomes worth authenticating some
or all DIS or DAO messages as well. 

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Tamás Holczer <[email-masked]>
Date: Fri, 25 Mar 2011 13:47:01 +0100

Dear Michael,

> I believe that it should be split up into two documents.

We will consider it for the next version/s.

> then presents a short solution.  I'd like to see the threat more clearly

We will try to clarify the threats and attacker model in the next
version of the draft. Mainly we are interested what can a compromised
node do. The source of the compromise can be logical [1] or physical [2].

The motivation to authenticate the version number in the DIO message is
the following:
 - DIO is mandatory
 - energy consumption
 - has network wide influence
 - all traffic can be hijacked

We will try to describe the motivation in the next version of the draft.

The motivation for the key exchange is the following:

 - elegant and efficient solution
 - assumption is quite realistic for LLNs
 - RPL sec framework mentions pairwise keys, but no specific algorithm
is given

Actually many other solutions for the key exchange can be implemented,
it is only one suggestion.

> scope for the base spec, which assumes all nodes are trusted)

Our two extensions are independent, section 3.2 is not intended to solve
the question of section 3.1 and vice versa.

> attack methods for closed networks operated by a single entity?

We will try to clarify the threats and attacker model in the next
version of the draft. Mainly we are interested what can a compromised
node do. The source of the compromise can be logical [1] or physical [2].

> vs how big can we make n?

How often do the version number increase: out of scope of this draft
(application depended).

For a normal node (Micaz) it is very costly to digitally sign and
verify, therefore we are using it only for bootstrapping or infrequently
to reload the hash chain.

It is a question of a trade-off between memory, computation of the DODAG
root and the cost of a signature verification [OptHash]. Note that using
the version authentication, only the root can increase the version
number, so it can control the exhaustion of the chain. Possibly, we will
be able to give some guidelines after analyzing the performance of our RPL
implementation.

> can send such messages, and we are really back to square one: all nodes

Possibly it is not clear from the text, that this key K is the same as
in section 3.2, meaning that it must be deleted after a small time. We
assume that it is not compromised before this safe time period. It can
be used to authenticate the first hash value received by the node. This
is not a suggested method, because it is impossible to reload the hash
chain after deleting K. This solution can be used for short or pre given
lifetime networks. We will clarify this in the next version of the draft.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

[1] A.Francillon and C.Castelluccia: Code Injection Attacks on
Harvard-Architecture Devices

[2] Ross Anderson, Markus Kuhn: Tamper Resistance – A Cautionary Note

[OptHash]  Don, C., and M. Jakobsson, "Almost Optimal Hash Sequence
              Traversal", Fourth Conference on Financial Cryptography,
              2002.

Best regards,

Tamás
- -- 
Tamas Holczer
Assistant Research Fellow
Laboratory of Cryptography and System Security (CrySyS)
Budapest University of Technology and Economics (BME)
URL: http://www.crysys.hu/members/tholczer/