[dtn-security] IBC for DTN

Rabin Patra <rkpatra@cs.berkeley.edu> Fri, 01 April 2005 20:17 UTC

Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j31KHcV13478 for <dtn-security@mailman.dtnrg.org>; Fri, 1 Apr 2005 12:17:38 -0800
Received: from [192.168.0.2] (c-24-5-195-71.hsd1.ca.comcast.net [24.5.195.71]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id j31KHWj6016912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 12:17:34 -0800 (PST)
Message-ID: <424DAC47.5060001@cs.berkeley.edu>
Date: Fri, 01 Apr 2005 12:17:11 -0800
From: Rabin Patra <rkpatra@cs.berkeley.edu>
User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dtn-security@mailman.dtnrg.org
CC: sonesh@eecs.berkeley.edu
References: <200503291631.j2TGV9j25051@smtp-bedford-dr.mitre.org> <424C6044.2070703@sparta.com>
In-Reply-To: <424C6044.2070703@sparta.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [dtn-security] IBC for DTN
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

Hi Howard,

Thanks a lot for your comments -
my response is below.

Meanwhile, a more complete version of the paper is here:
http://deccan.cs.berkeley.edu/~rkpatra/cs261/dtnsec/docs/proposal/dtn_ibe.pdf
The paper still needs cleanup, it is still a draft.

Here is a web page we made for this:
http://deccan.cs.berkeley.edu/~rkpatra/cs261/dtnsec/docs/proposal/

It also has comments from people (including Susan).
I will also add the recent draft security overview from Susan.


Howard Weiss wrote:
> 
> I went thru Rabin's paper and your comments.  Nothing I've seen so far 
> has changed my opinion regarding IBE - I don't think it solves anything 
> wrt DTN.  For example:
> 
> 1. On encrypting a transmission, the source gains a "win" by not having 
> to cache the destination's public key or consult a certificate 
> authority.  However, the source does have to cache the destination ID 
> information (which is presumably much smaller than a certifcate but 
> nevertheless, its infomation that somehow has to be arrived at and 
> cached).    The destination loses because its got to go to a PKG to get 
> a private key to match the source.  I guess the private key could be 
> cached but there is still a first time penalty.  Bottom line: a zero sum 
> gain.
> 
> 2. On signing, the sender has to obtain a private key for the 
> destination from a PKG or have the private key already cached.  The 
> destination "wins" by not having to consult with any server to 
> authenticate.  Another zero sum gain. 
> 
> One side wins at the expense of the other side.  This scheme seems like 
> it would work well if there are many encrypting sources but few 
> receivers.  The win is that the sources don't have to consult with any 
> servers (or use precious cache space) before sending.  But the 
> destination has to pay the piper because of the number of private keys 
> that have to be obtained or cached.


Well there could be a difference in total number of
key lookups. Suppose there 'n' hosts and they all want to
talk to each other. In PKI there would be a total of n^2
public key lookups as each sender now has to lookup all
the receivers. In IBE, each receiver has to get its
private key only once - so we have around 'n'
private keys lookups with the PKG
(the trusted key server in IBE).
This savings might be important in DTNs.


> In either a PKI-like instantiation or an IBE-like instantiation, there 
> is still a trusted 3rd party server involved that must be consulted.  I 
> can envision ways in a PKI instantiation where there are no servers 
> (e.g., I only have a DTN CA cert and I need to talk to entity A so I 
> first send a "hello" to A and attach my public signed by the DTN CA; A 
> replies with "how are you" and sends its public, also signed by the DTN 
> CA back to me; now I can send something encrypted - costs one round trip 
> but does not involve an 3rd party server than could also be a single 
> point of failure).  I can't see how this could be done with IBE - at 
> least its not clear to me.

This roundtrip might not be acceptable in DTNs.
Its true that a 3rd party server is needed in IBE, but only
to get private keys. Once everybody has their private keys,
no round trip is necessary to setup communication.
Infact we can send encrypted data to hosts without
waiting for them to get private keys first.
Even in PKI, you have to get your public
key certificate once.

Things are more complicated with revocation -
which might be a desirable feature for DTNs.
PKI supports explicit revocation either by publishing lists
of revoked hosts that have to be pushed to all hosts
or by requiring an explicit key lookup at the sender side
for every send operation - might be difficult in DTNs.

With an IBE system, revocation
has to be implicit - by requiring hosts to get periodically
get new private keys by adding date or time information
in the public string.
By using hierarchical IBE, hosts need to go
only to their local PKG server to get their private keys.
Thus, we can bring both the decision making for revocation
(which also might be local to the receiver 'region')
as well as the private key generation together in time and space.
Now senders do not need to bother with any lookups for
validation - at the cost of implicit certification of
receivers over some time period.

We also use the same hierarchy to achieve more
fine grained control over revocation.

There are still other issues with IBE - for example,
hosts cannot generate their own key pairs - thus key escrow,
the fact that identities are sort of fixed - cannot be easily
changed (unlike public keys in PKI), need to have a common standard
for format of the public ID string etc.


- Rabin


> Howie
> 
> Susan F. Symington wrote:
> 
>> Howie,
>>  
>> I have attached the paper.  I had thought it was sent out in 
>> dtn-interest but I just checked and you are right, it was sent to me 
>> and two other people. You may want to mention to Kevin to tell Rabin 
>> to add you to his list so if he ever updates it, you will be included 
>> in the mailing. 
>>  
>> I am also attaching the comments that I sent back to Rabin. 
>>  
>> -susan
>>
>>     ------------------------------------------------------------------------
>>     *From:* Howard Weiss [mailto:Howard.Weiss@sparta.com]
>>     *Sent:* Monday, March 28, 2005 5:38 PM
>>     *To:* Susan F. Symington
>>     *Subject:* Reference in DTN Security Overview and Motivation
>>
>>     Susan,
>>
>>     I am going through your DTN security overview and motivation and
>>     came across a reference to a paper:
>>
>>     Patra, R.; "Using Identity Based Crytography for Security in
>>     DTNs," December 2004.
>>
>>     I haven't seen this - I have only heard Kevin allude to someone
>>     looking at IBE.  If you have it, can you send it to me?
>>
>>     Thanks,
>>
>>     Howie
>>
>>-- 
>>Howard Weiss
>>SPARTA, Inc.
>>7075 Samuel Morse Drive
>>Columbia, MD 21046
>>410.872.1515 x201
>>410.872.8079 (fax)
>>
>>    
>>
>>------------------------------------------------------------------------
>>
>>Using Identity based Cryptography for Security in DTNs
>>------------------------------------------------------
>>
>>This proposal describes an architecture based on Hierarchical Identity Based 
>>Encryption for providing security features in DTNs.
>>The aim is to provide confidentiality and integrity
>>for end-to-end communication as well as protection of the DTN 
>>infrastructure and efficient implementation of access control in a 
>>heterogeneous environment of hosts having varied connectivity.
>>
>>
>>The requirements for such a security architecture in DTNs are :
>>1> Implicit certification:
>>    This means that a source(A) should be able to encrypt and send a bundle to the
>>    destination(B) by using only B's public information such that B will be able
>>    to decrypt the message only if it is currently certified [9].
>>    Otherwise, senders will have to explicitly verify the current status of
>>    receivers (whether their public keys are still valid) from a third-party 
>>    trusted authority.
>>    - we also don't want senders to store for each possible destination either 
>>      a) a shared private symmetric key or b) a public key
>>    - third party certification queries may also be difficult in DTN like 
>>      heterogeneous environment where the server that has the ability to certify B 
>>      is in a different administrative region than A.
>>    - we also want to ensure that no single entity is forced to handle all 
>>      certification queries/requests - this will lead to overload and increased 
>>      latency for queries.
>>
>>2> Control over revocation over different time scales:
>>    Implicit certification eliminates the need for the sender to perform
>>    third-party certificate status queries. But in a DTN heterogeneous 
>>    environment where hosts with different levels of vulnerability might
>>    exist, we also want allow the system ( or the certificate
>>    authorities) to choose between between fine grained or coarse grained
>>    revocation for each host.
>>    i.e if a user is more trusted, the system might want to re-certify
>>    keys only every month as opposed to doing it every day.
>>    
>>
>>3> Authentication for infrastructure access control:
>>    As already suggested in [1], bundles should carry two headers i.e PSH that
>>    is signed by the original source, and BAH that is signed at each hop by the
>>    sender router.
>>    Thus we need two different types of authentication mechanisms:
>>    Router authentication (in BAH): This is used by routers to authenticate
>>      the previous hop routers. Every router might have its own specific access
>>      control policy for each router it interacts with. 
>>      Though this implies that it needs to be aware of their identities,
>>      it can be feasible as the routers might need to know only their 
>>      immediate neighbors in the DTN.
>>    Source authenticating (in PSH): 
>>     - This is used for end-to-end integrity of the bundles.
>>     - It is used by the destination host for authentication of the source of bundle.
>>     - It can also used by routers for global policy access control using 
>>       the identity of source endpoints. As routers cannot be
>>       possibly be aware of all the sources in the world, it would make more sense
>>       if these rights are encoded in the credentials (or a certificate)
>>       presented by the source along with the bundle.
>>       For example, if a source is given permission to send all its traffic 
>>       in the 'Urgent' class by the system, the all routers need to support this. 
>>     - Instead of using certificates (which can be long)  for encoding the 
>>       rights of the source, we want these rights to be encoded in the 
>>       identity of the source endpoint. 
>>       Then a successful authentication of the identity of the 
>>       source should mean that source has obtained that particular identity
>>       from the system.
>>       For example: A source 'A' possessing 'Urgent' class  would have the
>>       identity 'A.Urgent'. We need to make sure that these identities can
>>       only be provided by the system and cannot be forged by some adversary.
>>     - This would also mean that identities of would have to be part of the
>>       bundle in the PSH.
>>        
>>4> Complex access control policies:
>>    As DTNs can conceivably have multiple classes of service,
>>    we need efficient ways to represent more complex access control policies.
>>    One way is to support policies over simple boolean expressions.
>>    For example: for source A: Urgent OR Bulk class traffic.
>>      
>>
>>Assumptions and Threat Model:
>>-----------------------------
>>1> The DTN can have global access control policies that need to recognized by
>>   all routers in all administrative regions. However routers can have their
>>   own specific access control policies. (it is not clear if these should be
>>   allowed to override the former).
>>2> There is a set of trusted servers in the DTN that cannot be compromised by 
>>   adversaries. These servers will be used for key issuance, management and
>>   revocation.
>>   Other hosts (including routers) in the DTN can be compromised.
>>3> Adversaries can eavesdrop on all traffic, they can capture bundles 
>>   and also modify in flight bundles.
>>
>>
>>Types of Attacks:
>>1> Routing level attacks : Adversaries on compromising routers can
>>   can change routing entries to create routing dead-ends or loops.
>>2> Infrastructure level attacks: Adversaries can try to access the DTN 
>>   infrastructure without authorization. 
>>   They can try to flood the network or send bundles with 
>>   classes of service that are not allowed.
>>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise 
>>   the confidentiality and integrity of the bundles in the DTN. 
>>   They can replay bundles.
>>
>>
>>    
>>Proposal:
>>---------
>>The basic proposal is to use a combination of Hierarchical Identity based
>>encryption (HIBE) and signatures (HIBS).
>>
>>
>>IBE in brief:
>>    An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where 
>>    any string is a valid public key. In particular, email addresses and dates
>>    can be public keys.
>>    When Alice sends mail to Bob at bob@hotmail.com she simply encrypts her 
>>    message using the public key string ``bob@hotmail.com''. There is no need for
>>    Alice to obtain Bob's public key certificate. When Bob receives the 
>>    encrypted mail he contacts a third party, the Private Key Generator (PKG), 
>>    Bob authenticates himself to the PKG in the same way he would authenticate 
>>    himself to a CA and obtains his private key from the PKG.
>>
>>    IBE scheme consists of four algorithms: 
>>    (1) Setup: The PKG generates global system parameters and a master-key.
>>        The global system parameters need to be distributed to all hosts
>>        initially.
>>    (2) Extract: The PKG uses the master-key to generate the private key 
>>        corresponding to an arbitrary public key string ID, 
>>    (3) Encrypt: Source(A) encrypts messages using the public key ID of the
>>        destination, B.
>>    (4) Decrypt: B decrypts messages from A using the corresponding private key 
>>        that it obtained from the PKG.
>>    
>>    IBE has been proven to be secure against chosen cipher-text attacks in the 
>>    random oracle model.
>>    For more details please refer to [7]
>>    
>>    IBE based signatures schemes have also be proposed where the source can
>>    sign using its private key and the signature can be verified using the
>>    public ID string.
>>    
>>Hierarchy IBE [9] in brief:
>>    The main problem of plain IBE where the single PKG has to issue private
>>    keys for all users is mitigated by creating a hierarchy of PKGs.
>>    Hierarchy is established in the form of a tree where each 
>>    (and root) node can be a separate PKG.
>>    The identity of a particular node at level t is given by its 
>>    ID-tuple (ID1,ID2..IDt) where  ID_i corresponds to the i-th level node.
>>    For key extraction, each PKG(root or lower level one) at level t may
>>    obtain the private keys for its immediate children with ID tuple
>>    (ID1,ID2..IDt,ID_t+1).
>>    Encryption and decryption proceed similarly as IBE and the ID Tuple is used
>>    as the public key.
>>    Similar scheme can be developed for Hierarchical IB Signatures.
>>    It is also proven that HIBE is secure against collusion among lower level
>>    PKG servers.
>>
>>Bundle Transmission:
>>1> The source first uses the destination node's public ID string to encrypt
>>   the bundle. This cipher-text forms the payload of the bundle.
>>2> The PSH is then created over the payload and header (with appropriate
>>   fields zeroed out) by signing with the 
>>   source endpoint ID ( that encapsulates the requisite access control permissions).
>>   The integrity can be verified and the source identity can be 
>>   authenticated by all routers.
>>   This was one of the features desired in [1] (point 12). 
>>3> The BAH is created at each hop by the sending router. This can be done
>>   using some other cryptographic scheme (symmetric or assymmetric) also.
>>
>>Now lets see how the different requirements specified are solved:
>>1> Implicit certification:
>>    As is clear from the basic definition of IBE, a source need not know the
>>    public key of the destination before sending a bundle. 
>>    The burden of ensuring updated certification now rests on the 
>>    destination that now has to obtain the current valid private key 
>>    to be able to decrypt a received bundle.
>>
>>2> Use of hierarchy:
>>    This offers us two advantages:
>>    a> Efficient key distribution: Normal IBE has only one PKG server which 
>>      possesses the master key. This PKG is responsible for extracting private
>>      keys of all the users of the system. 
>>      By using hierarchy - a) we can first place local PKGs in every region so that
>>      destination nodes dont have to go far to get their private keys and
>>      also b) compromise of a lower level PKG does not compromise the whole
>>      system (as the master secret resides with the root PKG only).
>>      The naming scheme in HIBE also derives naturally from the naming in the DTN 
>>      architecture where the endpoint address consists of two parts - region
>>      ID and the region-specific ID.
>>      For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then
>>      a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can
>>      further create more levels in the hierarchy.
>>
>>    b> Revocation control: 
>>      We do this by creating a sub-hierarchy for each host (in addition to the
>>      hierarchy over multiple PKGs created for key distribution). 
>>      The levels in this sub-tree would reflect the degree of control desired
>>      for revocation. Senders will use the ID tuples corresponding to the
>>      leaves of this tree for encryption.
>>      As this sub-tree is completely located at a particular
>>      host, the host can act as a PKG and extract private keys for this tree 
>>      on its own. We can control the leaves for which the host is able to generate
>>      private keys for itself by providing it private keys for only selected
>>      internal nodes of this tree.
>>      For example: the first level could be month, the second level date and 
>>       the third level: hour. Then the ID of a user Bob (in region Earth) would be
>>       Earth.Bob.May.24.12pm . 
>>       - The Earth region PKG can extract private keys for all IDs of the form 
>>         'Earth.*'. The Earth PKG can then choose to give Bob the private key 
>>         for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all 
>>         keys of the form 'Earth.Bob.<month>.<date>.<hour>. 
>>       - A less trusted user 'Alice' will be given the private key for
>>         'Earth.Alice.Nov' only - this will allow Alice to read messages only for
>>         month of November. For a bundle encrypted with the full ID string
>>         Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private
>>         key every hour.
>>       - For more paranoid uses, an extra level of the this tree could be a
>>         random ID. This would force the receiver to acquire a new private key
>>         for each bundle it receives. A sender can now encrypt the bundle 
>>         with 'Earth.Alice.Nov.25.12pm.<random_id>'.
>>       - A sender that wishes lower security( and lower latency) for a
>>         session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice
>>         would have to go to the Earth PKG only once to decrypt this bundle.
>>      In general, the PKG server responsible for a user needs to compute a
>>      subset cover over the user subtree i.e the minimum set of nodes that cover
>>      all the IDs that are allowed and none of the IDs that are not allowed
>>      for that user. Then it needs to extract private keys for only those
>>      nodes in the subset cover.
>>      
>>    c> Fine grained access control:
>>     A similar scheme as above can be used for forming ID strings needed for
>>     authentication and access control as well.
>>     For this source users sign the bundles with the correct privilege
>>     desired. For example, if Alice desires 'Urgent' class of service, it will
>>     need to sign the bundle with the identity 'Alice.Urgent'. For this it
>>     needs to possess the private key corresponding to 'Alice.Urgent'. 
>>     Possession of a private key corresponding to an identity
>>     implies that the system also authorized you for the rights that are
>>     associated with that identity.
>>     This is possible in IBE because all private keys are generated by the PKGs.
>>     The same hierarchical ID structure can be used for revocation and
>>     granting of rights as well. The subtree below each host
>>     would now represent different privileges.
>>     For example: A highly valuable Bob can be given access to all classes
>>      of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can
>>      then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for
>>      signing his bundles.
>>      A less valuable 'Alice' will only be given the private key for
>>      'Earth.Alice.Nov.25.Bulk'.
>>     However this mechanism requires the ID string to be included
>>     in the bundle header(PSH) for routers to use the correct key
>>     for authentication.
>>     This issue was raised in [1] as well for key rollover.
>>     This overall method of encoding the permissions of the user in the ID
>>     string is very similar to using accompanying certificates in traditional PKI.
>>
>>Why not PKI?:
>>-------------
>>1> Implicit certification is not possible as a source host is forced to 
>>   first acquire the identity(public key) of the destination before sending
>>   any bundle. It is also forced to check
>>   whether the destination is currently certified or not by making third-party
>>   queries.
>>2> Revocation is made much difficult in DTN and solutions like maintaining 
>>   a Certificate Revocation List(CRL) does not work for DTNs.
>>
>>Other issues and Disadvantages:
>>-------------------------------
>>1> Key escrow: 
>>    In IBE, the PKG can generate private keys for all users and thereby decrypt
>>    bundles destined for all users. This may not be always desirable.
>>    A related property is 'non-repudiability' which means that a receiver can
>>    prove that only the sender could have signed the bundle.
>>    Also, the compromise of the root PKG jeopardizes the entire system
>>    and all messages that were sent in the past.
>>
>>2> Standards issue:
>>    Since we try to encode revocation control(date etc) and access control
>>    identifiers in the ID strings, all entities in the DTN need to agree on a
>>    common format. This is similar to the problem faced in traditional PKI
>>    over the format of certificates.
>>    
>>3> Distribution of private keys:
>>    Since users ask the PKGs to generate private keys, they have to be transmitted 
>>    securely from the PKGs. This might mean that the PKGs share another key
>>    with every user just for the purpose of sending private keys.
>>
>>5> Distribution of system wide public parameters
>>    An IBE system installation needs to bootstrap all hosts with
>>    the public system parameters of the PKG. 
>>    This also might need to be updated if the root PKG is compromised.
>>
>>6> Replay attacks:
>>    Although we guarantee confidentiality and integrity, we do not have any
>>    mechanism to detect and handle replay attacks.
>>    
>>Other options and optimizations:
>>--------------------------------
>>1> Use of Certificate Based Encryption [8]:
>>   The 'key escrow' problem can be solved by using this variation where users
>>   are allowed to generate their own private keys.
>>   Senders are now able to user long lasting public keys without the need
>>   to worry about the current certification status of the destinations.
>>   This also solves the problem of securely delivering extracted private keys
>>   to each user.
>>2> Reducing overhead of using hierarchical IBE:
>>    Normal HIBE, both the length of signatures and the number of steps required
>>    for encryption are proportional to the number of levels in the ID tree.
>>    Some techniques based on the BGLS aggregated signature scheme can be used
>>    to reduce the decryption complexity.
>>3> If non-repudiability is not desired, them the scheme proposed in [10] can be
>>   used. Here the the MAC for authentication is same as the cipher-text for 
>>   encryption. It also uses the same public IDs and private keys as the standard
>>   scheme. So we can get both authentication(+integrity) and secrecy with
>>   little extra cost.
>>
>>
>>Implementation in DTN2 :
>>-----------------------
>>1> What are the basic building blocks that need to be supported in the DTN2
>>   architecture.
>>2> User management: [1] suggested that the DTN agent cannot possess the
>>   private keys. Applications should store the keys and call external
>>   entity to perform the encryption. 
>>
>>
>>
>>
>>
>>
>>References:
>>-----------
>>[1] Email correspondence on the dtn-interest mailing list
>>[2] Draft: "Identity based Encryption for Delay Tolerant Networks"
>>    A. Chakrabarti and K Fall.
>>    summary: proposes the use of IBE for both confidentiality as well
>>    as access control management in DTNs.
>>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al.
>>    summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient
>>     key management in the TCA.
>>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing
>>    Information"
>>    Urs Hengartner and Peter Steenkiste
>>    summary: proposes use of HIBE for both "encryption-based" and
>>     "proof-based" access control for client-server interactions.
>>     More emphasis on preventing leakage of information about access control
>>     policies
>>[5] "Hidden Credentials" 
>>    
>>    summary: use of IBE for hidden credential trust negotiation.
>>[6] "Identity based signatures"
>>    Paterson
>>    summary: one scheme for signatures based on the Boneh/Franklin scheme.
>>[7] "Identity based Encryption based on the Weil Pairing"
>>    Boneh and Franklin
>>    summary: this introduces the first concrete IBE scheme.
>>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" 
>>    Craig Gentry
>>    summary: this talks about mitigating problems in IBE by proposing
>>     Certificate based Encryption(CBE) in which users can choose their own
>>     private key.
>>[9] "Hierarchical ID based Cryptography"
>>    Gentry and Silverberg
>>    summary: this extends the Boneh/Franklin IBE scheme 
>>[10]"Authenticated Identity-based Encryption"
>>    Ben Lynn
>>    summary: extends the Boneh/Franklin scheme to provide integrity of the
>>     message being encrypted.
>>      
>>
>>
>>  
>>
>>------------------------------------------------------------------------
>>
>>Rabin,
>>
>>Thank you very much for sending me your draft proposal for using IBE for security in DTNs. I appreciate having the opportunity to review it. There are a lot of good things in this paper. Of course, I won't be dwelling on them in my comments, it being the nature of comments to focus on areas that could be improved or clarified. I just want to make clear that my general reaction is very positive before I start pointing out areas that got me thinking.
>>
>>1. In your "Requirements" section, it seems to me that you have an additional implicit requirement that you really should make explicit, and that is the reuqirement of "Implicit public key distribution". This may seem obvious to someone who has been immersing himself in papers on IBE, but for the rest of us it is a novel concept, and I don't think it should be conflated with the concept of "implicit certification" as it now seems to be. By "Implicit public key distribution" I mean the ability of a user to derive the public key of an arbitrary user from some known information, such as his identity, thus eliminating the need for the user to obtain the public key from a third-party. I think your proposal would be more clear if you were to explicitly list "implicit public key distribution" (or whatever you choose to call it) as a separate requirement. It would also help to clarify the essence of "implicit certification", which is to addresses the issue of how a user who uses a 



p
>>ublic key derived from known information can be sure that the public key is still valid. The concept of getting the public key is separate from the concept of determining that the public key is still valid, and they should be treated as separate concepts. 
>>
>>2. Also in the "Requirements" section (#3, Authentication for Infrastructure access control) you say that you want the source's rights (permissions) to be encoded in  the identity of the source endpoint. But the permissions that are being requested are already encoded in the COS field. It seems a waste to also put the COS information in the source ID field. If the public key that is necessary to authenticate the bundle signature consists of a standard string composed of:
>>source endpoint id.COS.day/month/year/time(depending on granularity desired) then there is no need to put the COS information in the source ID field. 
>>By using the COS field as part of the public key encoding, you would have a straightforward mapping between the public key used both to authenticate the bundle and to thereby certify the right of the source to use this class of service, and the class of service rights that the bundle is requesting. This way, only the source ID and the validity period need be encoded in the source ID field. (Also, you may want to consider having the validity period encoded in a separate field of the bundle header rather than encoding it as part of the source ID field.) 
>>
>>3. In your section with the heading "Assumptions and Threat Model:" you have an aside stating that it is not clear if a given router's own specific access control policy should be allowed to override the global DTN access control policies that need to be recognized by all routers. My opinion is that a given router's own access control policy should be allowed to be more restrictive than the global access control policy, but it should not be allowed to be less restrictive than the global access control policy. In other words, all routers should be able to depend on all DTN bundle agents to enforce a given level of access control in determining what traffic they admit to the DTN from DTN applications; if a given router wants to be more restrictive on a given link within the DTN, that's its prerogative, and it should be able to do so (in fact, as I see it, the ability to be more restrictive is the whole point of having security policy routers). 
>>
>>4.In the "Types of Attacks" section you mention that adversaries may create routing loops. It should be noted that this is a problem that we have not yet addressed. Right now we don't have a way in the protocol to detect such an attack, and we don't really plan to be able to detect replays, so it isn't clear if or how we are planning to address this threat.
>>
>>5. In the "Bundle Transmission" section, step 2 does not make sense to me, and I think it may be an error that needs correcting. You say that the PSH is signed with the source endpoint ID. Don't you mean that it is signed with the PRIVATE KEY that corresponds to the source endpoint ID (and, if you accept my suggestion in item 2 above, it would be the private key that corresponds to the string formed by "source endpoint ID.COS.validity_time_period")? Then, any receiver can authenticate the source identity and its permissions by using the public key that is derived from the source endpoint id (or that may be exactly the source endpoint ID). 
>>
>>It should be noted (assuming I am understanding it correctly) that for any given validity time period, a single source may need to have as many as n private keys, where n is the number of different classes of service that can be represented. 
>>
>>6. In the "Bundle Transmission" section, step 3 surprises me. Don't you want to make a suggestion about how the BAH should be authenticated, or are you just leaving this for a later paper? If you are going to leave it out, which would be fine, then you should probably go back and refocus the paper to make it clear that you are really "only" addressing the end-to-end confidentiality and integrity security features of DTNs as provided by the PSH and "efficient implementation of access control in a heterogeneous environment of hosts ..." as provided by the PSH, but that discussion of infrastructure protection isn't within the scope of this paper.
>>
>>7. In your "Now lets see how the different requirements specified are solved:" section, you don't step through all the requirements that you originally proposed. This sort of thing causes those of us who are obsessive compulsive to develop all sorts of ticks and twitches. Addressing each requirements as it was originally raised would give readers like me just the sort of false sense of security that I need to sleep well at night. 
>>
>>8. In item 1 (Implicit certification) of the "Now lets see how the different requirements specified are solved:" section, you say that "a source need not know the public key of the destination before sending a bundle".  I think you really mean two things (and this goes back to my suggestion that you separate the concepts of key distribution from key certification).  I think you mean:
>> a) a source need not "look up" (as opposed to "know") the public key of the destination, and
>> b) a source need not obtain a destination's certification status before sending encrypted data to the destination as the bundle payload.
>>
>>9.In the "b> Revocation control:" section, it is worth noting (if I understandthe proposal correctly and completely) that the revocation mechanism being used is key expiration. There is no way to explicitly invalidate or revoke a private key from a user at an arbitrary time, once the key has been given to the user. Therefore, if a user Alice has been given a private key corresponding to the public key "Alice.October", this key will continue to work  through midnight on October 31, even if this key is compromised on October 1. For 30  more days, sources sending to Alice will encrypt bundle payload destined for Alice and send it to her thinking that its confidentiality is being protected even though it isnt. Therefore, the selection of the duration of a key's validity time period is an important choice and it would be good to make this clear to the reader. 
>>
>>Also, it isn't clear what the relationship is between the key's validity time period and the current real-world time. Is this relationship checked at the sender or at the recipient, or both? And how exactly is it checked?  For example,
>>If the current month is March, will a sender be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.April? How about using the public key Alice.February? 
>>It seems that if the current month is March, senders should not be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.February because the Alice.February key has expired and therefore it cannot be assumed to be safe to use it. 
>>
>>If Alice receives a bundle in the month of April but the bundle had been encrypted during the previous month, with the Alice.March key (which may very well happen in DTN), then what should Alice do? If she has cached the Alice.March key, then she will be able to decrypt the message, but should she? is her private key still valid?
>>
>>In other words, validity time periods may be such that a message that is sent during a validity time period will not be received until after that period is over. How should this be dealth with?  
>>
>>10. In the "Why not PKI?:" section, I am not convinced by your argument that the IBE scheme is better than the PKI scheme because when using PKI, the source host is forced to check whether the destination is currently certified or not by making third-party queries before it can send an encrypted bundle to the destination. (This is related to my comment in 9 above.) In a PKI scheme, when a source receives a destination's public key from the CA, can't that key come with a validity period, that says the key is good for the month of October, for example, and then it expires after that. If so, the source would not have to check the validity of that key before using it anytime during the month of October. The result is very similar to the result you get when using the IBE scheme using the sub-hierarchy scheme that corresponds to the month/day/hour of validity. In this respect, I don't see how the IBE scheme is any better than a PKI scheme that issues keys with validity time perio



d
>>s. Am I missing something? Both schemes seem to suffer from the fact that explicit revocation is not possible, making it impossible to revoke a certificate before its intended expiration date. At least in the PKI scheme it would be possible for a sender to query the CA to inquire whether the public key is still valid. There does not seem to be any analogous way for a sender using IBE to make such a query. To be safe, the user would have to use a random ID field in the ID string, in effect requiring a new public key to transmit each bundle (and therefore a new private key to decrypt each bundle). Distribution of the private key from the PKG to the DTN node is a not without its costs. Is there really an advantage to IBE over PKI in the respect that you mention in this section and, if so, can you please state it more clearly?
>>
>>11. In general, the paper would benefit if you were to make a more clear separation between the use of (and benefits of using) IBE for encrypting data versus for authenticating data, because those two operations are essentially the inverse of each other and they may be performed simultaneously on a given bundle sent in DTN. If the application data unit is encrypted and the bundle is signed using the PSH, then it isn't clear how the necessary public key and key validity information for both keys would be conveyed from source to destination. Your proposal talks of using the source ID field to convey the information necessary for the recipient to obtain the public key required to verify the bundle's PSH signature. How would the recipient know how to obtain the appropriate private key that it would also need to decrypt the application protocol data unit (APDU)? For example, if I understand your proposal correctly:
>>
>>On a bundle sent from Bob to Alice:
>>
>>Bob encrypts the APDU using the public key Alice.October and
>>Bob signs the bundle (in the PSH) with the private key corresponding to Bob.October.25.Urgent
>>
>>Upon receipt of the bundle, Alice would first use the public key Bob.October.25.Urgent to verify the signature in the PSH. Assuming the signature verified correctly, Alice would now get from her PKG (if she doesn't already have it) the private key corresponding to Alice.October and use it to decrypt the APDU.
>>
>>According to your proposal, the source ID has the information "Bob.October.25.Urgent" in it, so this is how Alice knows what public key to use to verify the signature in the PSH. How does Alice know that she needs the Alice.October private key (as opposed to the Alice.October.25 private key) to decrypt the APDU?  Is this string merely put into a new encryption keyID field that is carried in the bundle header?
>>
>>12. I hope IBE really woudl be secure in a DTN application and that that it will stand up to the test of time and increased scrutiny. It seems to be a genuine breakthrough that lots of folks have latched onto, but I don't feel qualified to make a judgement on its technical merits. Given that it hasn't had the scrutiny of PKI, I think it's important that DTN be designed so that it will work with both PKI and IBE. We need to be careful to define the protocols so that they don't have any hidden dependencies on the use of IBE.
>>
>>13. What about implementing IBE. Are there any implementations readily available that can be used with DTN2 or will this be something that will require a lot of development?
>>
>>Again, thanks for the opportunity to review this. I hope my comments help.
>>
>>-susan
>>
>>***********************************************************************
>>
>>Using Identity based Cryptography for Security in DTNs
>>------------------------------------------------------
>>
>>This proposal describes an architecture based on Hierarchical Identity Based 
>>Encryption for providing security features in DTNs.
>>The aim is to provide confidentiality and integrity
>>for end-to-end communication as well as protection of the DTN 
>>infrastructure and efficient implementation of access control in a 
>>heterogeneous environment of hosts having varied connectivity.
>>
>>
>>The requirements for such a security architecture in DTNs are :
>>1> Implicit certification:
>>    This means that a source(A) should be able to encrypt and send a bundle to the
>>    destination(B) by using only B's public information such that B will be able
>>    to decrypt the message only if it is currently certified [9].
>>    Otherwise, senders will have to explicitly verify the current status of
>>    receivers (whether their public keys are still valid) from a third-party 
>>    trusted authority.
>>    - we also don't want senders to store for each possible destination either 
>>      a) a shared private symmetric key or b) a public key
>>    - third party certification queries may also be difficult in DTN like 
>>      heterogeneous environment where the server that has the ability to certify B 
>>      is in a different administrative region than A.
>>    - we also want to ensure that no single entity is forced to handle all 
>>      certification queries/requests - this will lead to overload and increased 
>>      latency for queries.
>>
>>2> Control over revocation over different time scales:
>>    Implicit certification eliminates the need for the sender to perform
>>    third-party certificate status queries. But in a DTN heterogeneous 
>>    environment where hosts with different levels of vulnerability might
>>    exist, we also want allow the system ( or the certificate
>>    authorities) to choose between between fine grained or coarse grained
>>    revocation for each host.
>>    i.e if a user is more trusted, the system might want to re-certify
>>    keys only every month as opposed to doing it every day.
>>    
>>
>>3> Authentication for infrastructure access control:
>>    As already suggested in [1], bundles should carry two headers i.e PSH that
>>    is signed by the original source, and BAH that is signed at each hop by the
>>    sender router.
>>    Thus we need two different types of authentication mechanisms:
>>    Router authentication (in BAH): This is used by routers to authenticate
>>      the previous hop routers. Every router might have its own specific access
>>      control policy for each router it interacts with. 
>>      Though this implies that it needs to be aware of their identities,
>>      it can be feasible as the routers might need to know only their 
>>      immediate neighbors in the DTN.
>>    Source authenticating (in PSH): 
>>     - This is used for end-to-end integrity of the bundles.
>>     - It is used by the destination host for authentication of the source of bundle.
>>     - It can also used by routers for global policy access control using 
>>       the identity of source endpoints. As routers cannot be
>>       possibly be aware of all the sources in the world, it would make more sense
>>       if these rights are encoded in the credentials (or a certificate)
>>       presented by the source along with the bundle.
>>       For example, if a source is given permission to send all its traffic 
>>       in the 'Urgent' class by the system, the all routers need to support this. 
>>     - Instead of using certificates (which can be long)  for encoding the 
>>       rights of the source, we want these rights to be encoded in the 
>>       identity of the source endpoint. 
>>       Then a successful authentication of the identity of the 
>>       source should mean that source has obtained that particular identity
>>       from the system.
>>       For example: A source 'A' possessing 'Urgent' class  would have the
>>       identity 'A.Urgent'. We need to make sure that these identities can
>>       only be provided by the system and cannot be forged by some adversary.
>>     - This would also mean that identities of would have to be part of the
>>       bundle in the PSH.
>>        
>>4> Complex access control policies:
>>    As DTNs can conceivably have multiple classes of service,
>>    we need efficient ways to represent more complex access control policies.
>>    One way is to support policies over simple boolean expressions.
>>    For example: for source A: Urgent OR Bulk class traffic.
>>      
>>
>>Assumptions and Threat Model:
>>-----------------------------
>>1> The DTN can have global access control policies that need to recognized by
>>   all routers in all administrative regions. However routers can have their
>>   own specific access control policies. (it is not clear if these should be
>>   allowed to override the former).
>>2> There is a set of trusted servers in the DTN that cannot be compromised by 
>>   adversaries. These servers will be used for key issuance, management and
>>   revocation.
>>   Other hosts (including routers) in the DTN can be compromised.
>>3> Adversaries can eavesdrop on all traffic, they can capture bundles 
>>   and also modify in flight bundles.
>>
>>
>>Types of Attacks:
>>1> Routing level attacks : Adversaries on compromising routers can
>>   can change routing entries to create routing dead-ends or loops.
>>2> Infrastructure level attacks: Adversaries can try to access the DTN 
>>   infrastructure without authorization. 
>>   They can try to flood the network or send bundles with 
>>   classes of service that are not allowed.
>>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise 
>>   the confidentiality and integrity of the bundles in the DTN. 
>>   They can replay bundles.
>>
>>
>>    
>>Proposal:
>>---------
>>The basic proposal is to use a combination of Hierarchical Identity based
>>encryption (HIBE) and signatures (HIBS).
>>
>>
>>IBE in brief:
>>    An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where 
>>    any string is a valid public key. In particular, email addresses and dates
>>    can be public keys.
>>    When Alice sends mail to Bob at bob@hotmail.com she simply encrypts her 
>>    message using the public key string ``bob@hotmail.com''. There is no need for
>>    Alice to obtain Bob's public key certificate. When Bob receives the 
>>    encrypted mail he contacts a third party, the Private Key Generator (PKG), 
>>    Bob authenticates himself to the PKG in the same way he would authenticate 
>>    himself to a CA and obtains his private key from the PKG.
>>
>>    IBE scheme consists of four algorithms: 
>>    (1) Setup: The PKG generates global system parameters and a master-key.
>>        The global system parameters need to be distributed to all hosts
>>        initially.
>>    (2) Extract: The PKG uses the master-key to generate the private key 
>>        corresponding to an arbitrary public key string ID, 
>>    (3) Encrypt: Source(A) encrypts messages using the public key ID of the
>>        destination, B.
>>    (4) Decrypt: B decrypts messages from A using the corresponding private key 
>>        that it obtained from the PKG.
>>    
>>    IBE has been proven to be secure against chosen cipher-text attacks in the 
>>    random oracle model.
>>    For more details please refer to [7]
>>    
>>    IBE based signatures schemes have also be proposed where the source can
>>    sign using its private key and the signature can be verified using the
>>    public ID string.
>>    
>>Hierarchy IBE [9] in brief:
>>    The main problem of plain IBE where the single PKG has to issue private
>>    keys for all users is mitigated by creating a hierarchy of PKGs.
>>    Hierarchy is established in the form of a tree where each 
>>    (and root) node can be a separate PKG.
>>    The identity of a particular node at level t is given by its 
>>    ID-tuple (ID1,ID2..IDt) where  ID_i corresponds to the i-th level node.
>>    For key extraction, each PKG(root or lower level one) at level t may
>>    obtain the private keys for its immediate children with ID tuple
>>    (ID1,ID2..IDt,ID_t+1).
>>    Encryption and decryption proceed similarly as IBE and the ID Tuple is used
>>    as the public key.
>>    Similar scheme can be developed for Hierarchical IB Signatures.
>>    It is also proven that HIBE is secure against collusion among lower level
>>    PKG servers.
>>
>>Bundle Transmission:
>>1> The source first uses the destination node's public ID string to encrypt
>>   the bundle. This cipher-text forms the payload of the bundle.
>>2> The PSH is then created over the payload and header (with appropriate
>>   fields zeroed out) by signing with the 
>>   source endpoint ID ( that encapsulates the requisite access control permissions).
>>   The integrity can be verified and the source identity can be 
>>   authenticated by all routers.
>>   This was one of the features desired in [1] (point 12). 
>>3> The BAH is created at each hop by the sending router. This can be done
>>   using some other cryptographic scheme (symmetric or assymmetric) also.
>>
>>Now lets see how the different requirements specified are solved:
>>1> Implicit certification:
>>    As is clear from the basic definition of IBE, a source need not know the
>>    public key of the destination before sending a bundle. 
>>    The burden of ensuring updated certification now rests on the 
>>    destination that now has to obtain the current valid private key 
>>    to be able to decrypt a received bundle.
>>
>>2> Use of hierarchy:
>>    This offers us two advantages:
>>    a> Efficient key distribution: Normal IBE has only one PKG server which 
>>      possesses the master key. This PKG is responsible for extracting private
>>      keys of all the users of the system. 
>>      By using hierarchy - a) we can first place local PKGs in every region so that
>>      destination nodes dont have to go far to get their private keys and
>>      also b) compromise of a lower level PKG does not compromise the whole
>>      system (as the master secret resides with the root PKG only).
>>      The naming scheme in HIBE also derives naturally from the naming in the DTN 
>>      architecture where the endpoint address consists of two parts - region
>>      ID and the region-specific ID.
>>      For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then
>>      a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can
>>      further create more levels in the hierarchy.
>>
>>    b> Revocation control: 
>>      We do this by creating a sub-hierarchy for each host (in addition to the
>>      hierarchy over multiple PKGs created for key distribution). 
>>      The levels in this sub-tree would reflect the degree of control desired
>>      for revocation. Senders will use the ID tuples corresponding to the
>>      leaves of this tree for encryption.
>>      As this sub-tree is completely located at a particular
>>      host, the host can act as a PKG and extract private keys for this tree 
>>      on its own. We can control the leaves for which the host is able to generate
>>      private keys for itself by providing it private keys for only selected
>>      internal nodes of this tree.
>>      For example: the first level could be month, the second level date and 
>>       the third level: hour. Then the ID of a user Bob (in region Earth) would be
>>       Earth.Bob.May.24.12pm . 
>>       - The Earth region PKG can extract private keys for all IDs of the form 
>>         'Earth.*'. The Earth PKG can then choose to give Bob the private key 
>>         for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all 
>>         keys of the form 'Earth.Bob.<month>.<date>.<hour>. 
>>       - A less trusted user 'Alice' will be given the private key for
>>         'Earth.Alice.Nov' only - this will allow Alice to read messages only for
>>         month of November. For a bundle encrypted with the full ID string
>>         Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private
>>         key every hour.
>>       - For more paranoid uses, an extra level of the this tree could be a
>>         random ID. This would force the receiver to acquire a new private key
>>         for each bundle it receives. A sender can now encrypt the bundle 
>>         with 'Earth.Alice.Nov.25.12pm.<random_id>'.
>>       - A sender that wishes lower security( and lower latency) for a
>>         session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice
>>         would have to go to the Earth PKG only once to decrypt this bundle.
>>      In general, the PKG server responsible for a user needs to compute a
>>      subset cover over the user subtree i.e the minimum set of nodes that cover
>>      all the IDs that are allowed and none of the IDs that are not allowed
>>      for that user. Then it needs to extract private keys for only those
>>      nodes in the subset cover.
>>      
>>    c> Fine grained access control:
>>     A similar scheme as above can be used for forming ID strings needed for
>>     authentication and access control as well.
>>     For this source users sign the bundles with the correct privilege
>>     desired. For example, if Alice desires 'Urgent' class of service, it will
>>     need to sign the bundle with the identity 'Alice.Urgent'. For this it
>>     needs to possess the private key corresponding to 'Alice.Urgent'. 
>>     Possession of a private key corresponding to an identity
>>     implies that the system also authorized you for the rights that are
>>     associated with that identity.
>>     This is possible in IBE because all private keys are generated by the PKGs.
>>     The same hierarchical ID structure can be used for revocation and
>>     granting of rights as well. The subtree below each host
>>     would now represent different privileges.
>>     For example: A highly valuable Bob can be given access to all classes
>>      of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can
>>      then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for
>>      signing his bundles.
>>      A less valuable 'Alice' will only be given the private key for
>>      'Earth.Alice.Nov.25.Bulk'.
>>     However this mechanism requires the ID string to be included
>>     in the bundle header(PSH) for routers to use the correct key
>>     for authentication.
>>     This issue was raised in [1] as well for key rollover.
>>     This overall method of encoding the permissions of the user in the ID
>>     string is very similar to using accompanying certificates in traditional PKI.
>>
>>Why not PKI?:
>>-------------
>>1> Implicit certification is not possible as a source host is forced to 
>>   first acquire the identity(public key) of the destination before sending
>>   any bundle. It is also forced to check
>>   whether the destination is currently certified or not by making third-party
>>   queries.
>>2> Revocation is made much difficult in DTN and solutions like maintaining 
>>   a Certificate Revocation List(CRL) does not work for DTNs.
>>
>>Other issues and Disadvantages:
>>-------------------------------
>>1> Key escrow: 
>>    In IBE, the PKG can generate private keys for all users and thereby decrypt
>>    bundles destined for all users. This may not be always desirable.
>>    A related property is 'non-repudiability' which means that a receiver can
>>    prove that only the sender could have signed the bundle.
>>    Also, the compromise of the root PKG jeopardizes the entire system
>>    and all messages that were sent in the past.
>>
>>2> Standards issue:
>>    Since we try to encode revocation control(date etc) and access control
>>    identifiers in the ID strings, all entities in the DTN need to agree on a
>>    common format. This is similar to the problem faced in traditional PKI
>>    over the format of certificates.
>>    
>>3> Distribution of private keys:
>>    Since users ask the PKGs to generate private keys, they have to be transmitted 
>>    securely from the PKGs. This might mean that the PKGs share another key
>>    with every user just for the purpose of sending private keys.
>>
>>5> Distribution of system wide public parameters
>>    An IBE system installation needs to bootstrap all hosts with
>>    the public system parameters of the PKG. 
>>    This also might need to be updated if the root PKG is compromised.
>>
>>6> Replay attacks:
>>    Although we guarantee confidentiality and integrity, we do not have any
>>    mechanism to detect and handle replay attacks.
>>    
>>Other options and optimizations:
>>--------------------------------
>>1> Use of Certificate Based Encryption [8]:
>>   The 'key escrow' problem can be solved by using this variation where users
>>   are allowed to generate their own private keys.
>>   Senders are now able to user long lasting public keys without the need
>>   to worry about the current certification status of the destinations.
>>   This also solves the problem of securely delivering extracted private keys
>>   to each user.
>>2> Reducing overhead of using hierarchical IBE:
>>    Normal HIBE, both the length of signatures and the number of steps required
>>    for encryption are proportional to the number of levels in the ID tree.
>>    Some techniques based on the BGLS aggregated signature scheme can be used
>>    to reduce the decryption complexity.
>>3> If non-repudiability is not desired, them the scheme proposed in [10] can be
>>   used. Here the the MAC for authentication is same as the cipher-text for 
>>   encryption. It also uses the same public IDs and private keys as the standard
>>   scheme. So we can get both authentication(+integrity) and secrecy with
>>   little extra cost.
>>
>>
>>Implementation in DTN2 :
>>-----------------------
>>1> What are the basic building blocks that need to be supported in the DTN2
>>   architecture.
>>2> User management: [1] suggested that the DTN agent cannot possess the
>>   private keys. Applications should store the keys and call external
>>   entity to perform the encryption. 
>>
>>
>>
>>
>>
>>
>>References:
>>-----------
>>[1] Email correspondence on the dtn-interest mailing list
>>[2] Draft: "Identity based Encryption for Delay Tolerant Networks"
>>    A. Chakrabarti and K Fall.
>>    summary: proposes the use of IBE for both confidentiality as well
>>    as access control management in DTNs.
>>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al.
>>    summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient
>>     key management in the TCA.
>>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing
>>    Information"
>>    Urs Hengartner and Peter Steenkiste
>>    summary: proposes use of HIBE for both "encryption-based" and
>>     "proof-based" access control for client-server interactions.
>>     More emphasis on preventing leakage of information about access control
>>     policies
>>[5] "Hidden Credentials" 
>>    
>>    summary: use of IBE for hidden credential trust negotiation.
>>[6] "Identity based signatures"
>>    Paterson
>>    summary: one scheme for signatures based on the Boneh/Franklin scheme.
>>[7] "Identity based Encryption based on the Weil Pairing"
>>    Boneh and Franklin
>>    summary: this introduces the first concrete IBE scheme.
>>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" 
>>    Craig Gentry
>>    summary: this talks about mitigating problems in IBE by proposing
>>     Certificate based Encryption(CBE) in which users can choose their own
>>     private key.
>>[9] "Hierarchical ID based Cryptography"
>>    Gentry and Silverberg
>>    summary: this extends the Boneh/Franklin IBE scheme 
>>[10]"Authenticated Identity-based Encryption"
>>    Ben Lynn
>>    summary: extends the Boneh/Franklin scheme to provide integrity of the
>>     message being encrypted.
>>      
>>
>>
>>  
>>
> 
> -- 
> Howard Weiss
> SPARTA, Inc.
> 7075 Samuel Morse Drive
> Columbia, MD 21046
> 410.872.1515 x201
> 410.872.8079 (fax)
> 
>