Re: [dtn-security] Newbie seeking some security related advice

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 19 May 2009 08:40 UTC

Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n4J8eUq6012992 for <dtn-security@maillists.intel-research.net>; Tue, 19 May 2009 01:40:30 -0700
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 3261A1003F4BB; Tue, 19 May 2009 09:35:35 +0100 (IST)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVCW4kVGvtpB; Tue, 19 May 2009 09:35:34 +0100 (IST)
Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id B59BC1003F4AD; Tue, 19 May 2009 09:35:32 +0100 (IST)
Message-ID: <4A127006.4020108@cs.tcd.ie>
Date: Tue, 19 May 2009 09:38:30 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.21 (X11/20090302)
MIME-Version: 1.0
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@leonixsolutions.com>
References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com>
In-Reply-To: <4A12195A.6000207@LeonixSolutions.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dtn-security@maillists.intel-research.net
Subject: Re: [dtn-security] Newbie seeking some security related advice
X-BeenThere: dtn-security@maillists.intel-research.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DTN Security Discussion <dtn-security.maillists.intel-research.net>
List-Unsubscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=unsubscribe>
List-Archive: <http://maillists.intel-research.net/pipermail/dtn-security>
List-Post: <mailto:dtn-security@maillists.intel-research.net>
List-Help: <mailto:dtn-security-request@maillists.intel-research.net?subject=help>
List-Subscribe: <http://maillists.intel-research.net/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@maillists.intel-research.net?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 08:40:31 -0000

Hi Graham,

I guess the 1st question I'd ask is what it is you want to secure,
the identity of a next (dtn-)hop peer or the bundle headers and payload?
If the former, then it seems like you want some security from your
convergence layer, or the BSP's hop-by-hop authentication scheme. If
the latter then probably (some variant of) the BSP end-to-end spec.
The usual way to figure out which you want is to think about what bad
thing(s) you want to prevent, i.e. your threat model, and only after
you know that start to figure out what security mechanisms to use.

Either way, if you find a use for TESLA that'd be interesting.

Your MAC v. hash question doesn't make sense - neither is "more"
secure since they do different things. I'd recommend maybe reading
a bit more about, e.g. HMAC. (e.g. rfc 2104)

You should also check out Pete Lovell's BSP code which is
integrated into the DTN2 codebase.

Regards,
Stephen.

Graham Keellings (Leonix Solutions Pte Ltd) wrote:
> Someone recently asked me to look into a secure, ad-hoc, DTN network. It is likely to be a voice network, probably with SMS and possibly also some video.
> 
> There are not many resources available for the project, so it has been suggested to take a phased approach. With a few decades of telcoms, protocol stack, experience, but no DTN experience and not much idea of comms security beyond Kasumi F8 and F9 (cyphering and integrity (MAC), both usually done in hardware), I wonder if anyone would care to comment on this proposed roadmap (for which many thanks in advance...)
> 
>     * for the initial phase,just add MAC with secret key to the reference DTN
>       implementation at link establish and acknowledgement (*) and hand that
>       over to the cryptography guy to see if he can infiltrate,
>       subvert, eavesdrop or deny service at the network level.
> 
>     * since the project is mainly voice based we should scale up the
>       number of nodes at some point and see just how delay tolerant
>       voice is (not a security concern).
> 
>     * consider encrypting data as well as securing it with MAC, since
>       MAC secured data is broadcast in the clear (maybe of less concern
>       for voice?)
> 
>     * for all variants, run some profiling, to see how much timing
>       impact they are having and attempt again to break the security.
> 
>     * consider public key encryption. The drawback is the need for a key
>       distribution service, which is a very weak link.
> 
>     * consider TESLA for key distribution (although it cannot revoke the
>       secret key at will if a node is compromised, only at a pre-set
>       time in the future)
> 
>     * whether secret key of public key, we should give some
>       consideration to how we can secure the network if a handset is
>       lost, stolen, left in the coffee-shop, etc.
> 
>     * look again at DTLSR/OLSR. It may be very efficient, but it is also
>       power hungry as there is constant background traffic to keep the
>       network  updated. If the projected end device is battery powered,
>       we ought  to look at alternative link establishment mechanisms and
>       compare their impact (profiling/timing/traffic load) and security (not a security concern).
> 
> The main point to me is that they are proposing to authenticate only at link establishment and acknowledgement thereof(*), and not also as each bundle is transferred. I suppose they theory is that once you have verified a node then there is no need to further verify all subsequent traffic to/from that node, which cuts down on the system overhead of security. But, what do the gurus think? 
> 
>     * is security only at link establish really safe?
>     * should data also be encrypted
>     * how secure is MAC? One person is claiming that it is not good
>       enough and needs to supplemented by hashing which sounds strange
>       to me since I thought that MAC _is_ strong one-way hashing.
>     * any recommendations for a fast, secure, open source MAC code? Or
>       should I just pull something from source-forge?
>     * any ideas on key distribution without a central server? Or,
>       perhaps I can say that the "handsets" (or whatever) will be given
>       out at the start of every business day from a secure location
>       which could contain a key distribution server, and returned there
>       each night. However, if a handset is lost or compromised during
>       the day I would like a way to revoke it.
> 
>       Since each handset/node would have to have the public keys of all
>       other nodes loaded to it a the start of the day and would not be
>       able to query the server during the day, is there any easy way to
>       determine a reasonable number of nodes for such a network (or is
>       it just a matter of how much RAM each node has)?
>     * are there any other recommendations for security?
>     * Are there any existing open source implementation of a 'secure'
>       version of DTN2?
> 
> Sorry to ask so many questions. I am doing as much research as I can,
> although am somewhat hindered by lack of resources, so thought that I
> might ask the experts.
> 
> Sorry to trouble the list so(*) and thanks in advance for any reply.
> 
> With best wishes,
> 
> Graham
> 
> (*) since I _have_ troubled the list, I will be cheeky and ask if anyone
> knows exactly where in the code the link establish and acknowledgement
> are sent/received. I am ploughing my way through the DoxyGen, but if
> anyone can save me some trouble, I would be grateful.  Thnaks
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-security mailing list
> dtn-security@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-security