[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