[dtn-security] Newbie seeking some security related advice
"Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com> Tue, 19 May 2009 02:33 UTC
Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n4J2XSXg028856 for <dtn-security@maillists.intel-research.net>; Mon, 18 May 2009 19:33:28 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.135]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from <Graham@LeonixSolutions.com>) id 1M6F4H-0007HM-Q2; Mon, 18 May 2009 22:28:38 -0400
Message-ID: <4A12195A.6000207@LeonixSolutions.com>
Date: Tue, 19 May 2009 10:28:42 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <Graham@LeonixSolutions.com>
Organization: Leonix Solutions Pte Ltd
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: dtn-security@maillists.intel-research.net
References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk>
In-Reply-To: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk>
X-Enigmail-Version: 0.95.7
Content-Type: multipart/mixed; boundary="------------010606030604040703010808"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - sky.fastbighost.net
X-AntiAbuse: Original Domain - maillists.intel-research.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - LeonixSolutions.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [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 02:33:29 -0000
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] Re(2): [dtn-interest] Bundle Secur… Peter Lovell
- Re: [dtn-security] [dtn-interest] Bundle Security… Hans Kruse
- [dtn-security] Bundle Security Protocol Implement… M.Bhutta
- Re: [dtn-security] Newbie seeking some security r… Armando Caro
- Re: [dtn-security] Newbie seeking some security r… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] Newbie seeking some security r… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Newbie seeking some security r… Jason Redi
- Re: [dtn-security] Newbie seeking some security r… Armando Caro
- Re: [dtn-security] Newbie seeking some security r… Kristian Erik Hermansen
- Re: [dtn-security] Newbie seeking some security r… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] Newbie seeking some security r… Stephen Farrell
- Re: [dtn-security] Newbie seeking some security r… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Newbie seeking some security r… Kristian Erik Hermansen
- [dtn-security] Newbie seeking some security relat… Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(many): Is there a "secure" refe… Peter Lovell
- Re: [dtn-security] Re(2): Re(2): Is there a "secu… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Is there a "secure" reference … Peter Lovell
- [dtn-security] Re(2): Re(2): Re(2): Is there a "s… Peter Lovell
- [dtn-security] Re(2): Re(2): Is there a "secure" … Peter Lovell
- Re: [dtn-security] Re(2): Is there a "secure" ref… Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Is there a "secure" referen… Peter Lovell
- Re: [dtn-security] Is there a "secure" reference … Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Is there a "secure" referen… Peter Lovell
- Re: [dtn-security] Is there a "secure" reference … Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Is there a "secure" reference impl… Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Newbie seeking some securit… Peter Lovell
- Re: [dtn-security] Newbie seeking some security r… Jason Redi
- Re: [dtn-security] Newbie seeking some security r… Stephen Farrell
- Re: [dtn-security] Newbie seeking some security r… Ivancic, William D. (GRC-RHN0)
- Re: [dtn-security] Newbie seeking some security r… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Encrypted IP headers Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Encrypted IP headers Peter Lovell
- Re: [dtn-security] Encrypted IP headers Graham Keellings (Leonix Solutions Pte Ltd)
- [dtn-security] Re(2): Re(2): How do you feel abou… Peter Lovell
- Re: [dtn-security] Re(2): How do you feel about B… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Re(2): Re(2): Re(2): Is there … Ivancic, William D. (GRC-RHN0)
- [dtn-security] Re(2): Re(2): Re(2): Is there a "s… Peter Lovell
- [dtn-security] Re(2): How do you feel about Bonjo… Peter Lovell
- Re: [dtn-security] How do you feel about Bonjour/… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] How do you feel about Bonjour/… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] Re(2): Re(2): Is there a "secu… Graham Keellings (Leonix Solutions Pte Ltd)
- Re: [dtn-security] How do you feel about Bonjour/… Peter Lovell
- [dtn-security] How do you feel about Bonjour/Avah… Graham Keellings (Leonix Solutions Pte Ltd)