Subject: Re: [core] HIP identities and puzzle

From: René Hummen <[email-masked]>
Date: Fri, 05 Nov 2010 15:42:26 +0100

Hi Rene,

On 02.11.2010, at 20:56, Rene Struik wrote:
> Hi fellow-Rene:

we don't get the opportunity to say something like that too often :-)

> Quick questions re your description of the protocol:
> 1) With HIP, why does the responder sign two messages, rather than one. According to Tobias Heer's email (October 29, 2010, 11:14pm EDT), the first of these is offline and the second is online. Question, however, is what the benefit is. After all, offline signatures do not prove the responder's active participation with the protocol, so any party could just replay an offline signature.

You are of course right when saying that offline signatures do not prove the responder's active participation in the current handshake. Still, the offline signature binds the responder's DH key in the R1 to its identity. The freshness of the handshake is established through the HMAC in the R2 packet, for which the key was derived from the DH keys. The PK signature in R1 also ensures that parameters such as the PUZZLE (with a given difficulty) and the DH_GROUP_LIST have originally been sent by the responder. Otherwise, HIP would be open to new DoS and downgrade attacks.
The online signature in R2 is required to enable forwarding entities to check the successful conclusion of the handshake as part of HIP's middlebox-friendly design. Please note that the signature might also have another use that I am currently unaware of. One of the original HIP authors might know more about it. 

> 2) With HIP, the protocol flows imply that initiator and responder have to perform their computations consecutively (since key confirmation and ephemeral contributions are combined with one protocol flow). This seems inefficient: one would be much better off designing the protocol so as to allow parallelization of computationally expensive steps of the protocol.

HIP actually allows a receiver to pre-create R1 packets. This pre-creation includes the generation of the DH key pair and the PK signature over the R1 packet by excluding certain parameters in the HIP_SIGNATURE_2 [1] parameter. Furthermore, HIP allows an initiator to pre-create a DH key pair before the handshake and to use it during the creation of an I2.

The remaining computations need to be performed consecutively, as they show interdependencies with previous packets of the handshake:
I2.1) The generation of the DH KEYMAT is required for the I2 in order for the initiator to prove (by means of an HMAC) that he computed the correct symmetric key. The DH KEYMAT generation depends on information from R1 (i.e. the responder's DH public key).
I2.2) The PK signature in I2 needs to cover the initiator's public DH key and the puzzle solution (DoS protection mechanism) to authenticate the DH key and to prove that the initiator actively takes part in the exchange. The puzzle solution depends on the challenge in R1.

R2.1) The same line of argumentation as for (I2.1) is true for R2 with a dependency on the DH key in I2.
R2.2) The PK signature in the R2 could potentially already be pre-computed after receiving I1. Note, however, that the I1 is not protected cryptographically and might be spoofed.

> 3) With HIP, it is unclear what features make it more attractive than, e.g., "ECDH with signed exponents". After all, it does not seem to offer any computational benefits over the latter. Same remark, but now in comparison to (H)MQV: doesn't that alternative provide far better performance?

HIP not only provides an authenticated key exchange, but aims at solving a more fundamental problem: the dual role of IP addresses. By implementing the id/locator split, it enables, e.g., host mobility and multi-homing transparently for the transport layer and above. However, in my opinion, an aspect of HIP that might be very interesting for CoRE on the conceptual level is flexible packet structure of HIP. It provides a very flexible and authenticated signaling channel that allows to convey tailored information based on the requirements of specific scenarios.
Getting back to your question, HIP differs from pure key exchange protocols by providing a signaling channel and by defining replay and DoS protection mechanisms. From my point of view, it might still be interesting to see how MQV schemes could be integrate in HIP in order to further improve its efficiency.

> 4) With HIP, how does one party obtain the public signature verification key of the other party? (with the protocol flows shown, this is not communicated along the way).

As stated in my previous email, ID_x, where x in {I, R}, is the public key of the initiator and responder respectively.

> 5) With DEX, one seems to use static (i.e., non-ephemeral) contributions by either party (which seem then to be equated with identifiers of either party). If so, the DH scheme comes down to Static-(EC)DH. Does this imply that these static keys are cast in stone, i.e., never change over the lifetime of the device in which they are embedded? Or, is change hereto possible under certain circumstances?

From a protocol perspective, the DH key could be changed between any two connections. However, changing the DH key implies changing a device's identity. This might not be what one expects in all scenarios. I'm currently working on a draft about a certificate-based namespace that will allow changing the cryptographic identities while keeping a stable device identifier, so that the DH keys can be changed without changing the identifier of a host.

> 6) With DEX, if one uses static-DH, why not simply cash the DH key and use a symmetric-key only protocol instead?

Static DH allows to dynamically set up pair-wise encrypted channels in a memory efficient way, as each device only needs to store it's own DH key pair. With symmetric keys you would need to store a shared key with each device in the network in order to achieve pair-wise encrypted channels. Of course a choice between both approaches involves a trade-off in space vs. computational complexity. Still, it might be beneficial to add a resume mechanism to DEX in order to refer to previously generated keying material. Such a mechanism could easily be incorpoarated in to the HIP signaling channel.

> 7) With DEX, it is unclear why one would have ECR, DCR relate to CMAC. Your description suggests that ECR should use AES, but in which mode of operation? At first sight, one should be able to combine ECR and CMAC into one cryptographic AEAD transformation, so question is why this is not considered here.

In the current version of the DEX draft, it is assumed that AES-CBC is used for symmetric encryption and CMAC for MACing functions. It might be well worth looking, e.g., into AES CCM* as it is one of the supported modes in 802.15.4.

> 8) With DEX, couldn't one simplify the protocol flows by including a random value S_R already in the first message pass from responder to initiator ("R1") and computing the pair-wise key from S_R and SI on the initiator's side earlier on?

When sending S_R already in R1, the random value would not be encrypted and therefore be visible to a malicious node. Still, I don't see a problem with that right away given that S_I provides "sufficient" randomness and is well protected. The initiator could start generating the pair-wise key for the payload protocol early on. Note, however, that the responder is only authenticated after successful validation of R2 and, thus, the initiator would not want to use the pair-wise key before.

Let me know, in case I left one of your questions unanswered.

BR,
René

[1] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-03#section-5.2.14 

> Just a few questions that came up when studying your protocol flows (I did not review the RFCs you referred to for now).
> 
> Best regards, Rene
> 
> 
> On 02/11/2010 2:16 PM, René Hummen wrote:
>> Hello Rene,
>> 
>> please see my comments below.
>> 
>> 
>> On 29.10.2010, at 17:14, Tobias Heer wrote:
>>> Hello Rene,
>>> 
>>> thanks for picking this up again.
>>> 
>>> First, one has to distinguish HIP and DEX (as proposed by Robert). HIP is (as defined in 5201) the base protocol and DEX would be the trimmed down variant for resource constrained scenarios. However, the DEX is certainly still WIP and can probably be bent in one or the other direction (if needed). I am not an author of the DEX and I somehow ended up mandating HIP here although CoRE is certainly not my primary field of work. Hence, I'd like to state that my intention is not to claim that HIP is the best protocol for CoRE. I simply don't know CoRE well enough to make such statement. However, I can try to answer some questions related to HIP so that CoRE WG can make a sound decision on whether HIP is something to consider or if it isn't.
>>> 
>>> Am 29.10.2010 um 15:02 schrieb Rene Struik:
>>> 
>>>> Hi Tobias:
>>>> 
>>>> It would help to have some more insight into claimed functionality of the HIP protocol. We had some correspondence on this over the last 4 weeks, but unfortunately detail as to claimed security properties,
>>> I) Which specific security properties are unclear to you? Maybe we can narrow things down a bit. Otherwise I might end up repeating the whole protocol as described in RFC5201 here.
>>> 
>>>> distinguishing features w.r.t. other protocols,
>>> II) Distinguishing features of HIP are (in my opinion):
>>> 
>>> On a conceptual level:
>>> a) the implementation of the locator/identifier split,
>>> 
>>> b) the quite flexible protocol design (emphasis on extendability - many people have successfully used HIP for quite different scenarios by extending and modifying the base protocol without breaking compatibility),
>>> 
>>> c) the identity-focused namespace based on cryptographic identities,
>>> 
>>> d) its integration within the stack. Upper layers just use HITs like IPv6 addresses and HIP takes care of establishing and maintaining an authenticated and encrypted channel to the other host.
>>> 
>>> 
>>> Features on a more technical level are:
>>> e) A 4-way handshake that includes authentication of both peers, generation of a shared secret and set-up of an encrypted payload channel. Depending on the scenario, this four-way handshake might be better than, e.g., the multi-packet flight-based exchange of DTLS that sends more packets. However, I am aware that HIP needs optimizations in the form of DEX to avoid fragmentation and DTLS could probably be modified to avoid multi-packet flights.
>>> 
>>> f) DoS prevention: HIP implements two different mechanisms here: return routability checks and puzzles. However, depending on the scenario, these may be applicable or may be not applicable for CoRE. I'd be happy to discuss this.
>>> 
>>> All aforementioned points (a-f) are valid for HIP and DEX.
>>> I will gladly give a more detailed explanation of these points if you wish - just tell me which requires further elaboration.
>>> 
>>>> computational benefits over other approaches
>>> 
>>> HIP uses an authenticated Diffie Hellman key exchange. In terms of public key operations, it does:
>>> 
>>> 2 public key verifications at the Initiator side
>>> 1 public key verification at the Responder side
>>> 1 public key signature at the Initiator side
>>> 1 public key signature at the Responder side
>>> 1 offline public key signature at the Responder side
>>> 1 DH shared key generation at the Initiator side
>>> 1 DH shared key generation at the Responder side
>>> 
>>> This is certainly not an optimal design for tightly resource constrained devices. Hence, Robert tried to reduce the number of computations needed without changing the way HIP works.
>>> DEX (as proposed by Robert) uses a static Diffie Hellman key exchange and amounts to:
>>> 
>>> 1 DH shared key generation at the Initiator side
>>> 1 DH shared key generation at the Responder side
>>> 
>>> The actual cost of these operations depends on the chosen DH groups/ ECC curves but the set algorithms is interchangeable and can be adopted to the needs of the scenario.
>>> 
>>> The aforementioned numbers don't reflect the cost of the use of an additional third-party certificate (which I believe you would like to see in a handshake). Hence, certificate verification at the sender or receiver should be added to the cost if the scenario demands it.
>>> 
>>> I hope this gives you a rough feeling for the cryptographic cost of running HIP/DEX.
>>> 
>>>> Moreover, I still have trouble to understand how the protocol could facilitate separation of device ids and cryptographic objects, as seems to be beneficial in deployment scenarios, such as large scale manufacturing of sensor nodes.
>>> René Hummen is currently preparing a draft on the solution that I mentioned in my previous mail. I hope he is done before or shortly after Beijing. I hope this document will answer your questions.
>> As Tobias mentioned, I'm currently working on a draft about a certificate-based namespace for HIP. However, as I just started it recently, it might well take until after Beijing.
>> 
>>>> If you could elaborate and put the issues to rest, that would be great.
>>>> 
>>> Sure. I hope the explanations above shed some light on the open questions regarding HIP. I tried to put each argument/point to a new line to make it easy for you to indicate which you would like to discuss in more detail.
>>> 
>>>> For the benefit of easy comprehension, I would suggest a succinct description (perhaps, with mathematical description of security-relevant portions of the protocol flows, properties, etc?).
>>>> 
>>> I believe Rene Hummen is preparing this, too. I hope the sum of the cryptographic operations is enough for now to develop a feeling for the cost.
>> I'm not an author of the DEX draft myself, but I already discussed with Robert about the protocol and I'm very interested in the topic. That said, these are my thoughts and findings on HIP and DEX.
>> 
>> HIP and DEX both have - as Tobias pointed out before - a 4 way handshake. The initial packet (I1) triggers the handshake and does not contain any cryptographic mechanisms. I'll now go through the packet exchange of both protocols focusing on the remaining packets R1, I2 and R2 and describe the respective cryptographic portions. Note that Rx (i.e. R1 and R2) denotes a packet sent by the responder, whereas Ix (i.e. I1 and I2) represents a packet sent by the initiator.
>> 
>> HIP:
>> ------
>> 
>> 	Initiator								Responder
>> 
>> 			I1
>> 			------------------------------------>
>> 
>> 										Create eph. DH key pair: x, g^x
>> 
>>                  	R1: ID_R, g^x,  SIGN(ID_R, R1)
>> 			<------------------------------------
>> 
>> VER_SIG(ID_R, R1)
>> Create eph. DH key pair: y, g^y
>> DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input
>> Derive shared secret from DH KEYMAT: s
>> 
>> 			I2: ID_I, g^y, HMAC(s, I2), SIGN(ID_I, I2)
>>                	------------------------------------>
>> 
>> 										
>> 										VER_SIG(ID_I, I2)
>> 										DH KEYMAT: Derived using HKDF* on g^{xy}, salt and peer info as input
>> 										Derive shared secret from DH KEYMAT: s
>> 										HMAC(s, I2)
>> 
>> 			R2: HMAC(s, R2), SIGN(ID_R, R2)
>> 			<------------------------------------
>> 
>> HMAC(s, R2)
>> VER_SIG(ID_R, R2)
>> 
>> 
>> * The HMAC-based Key Derivation Function (HKDF) is defined in RFC5869.
>> 
>> ID_x represent the public key of the respective host. SIGN and VER_SIG use the private key as first parameter and the message as second input. Their cost of depend on the signature algorithm in use. HIP supports RSA, DSA and ECDSA. Likewise, HIP supports both classical DH and ECDH.
>> 
>> 
>> 
>> DEX:
>> -------
>> 
>> 	Initiator								Responder
>> 
>> 			I1
>> 			------------------------------------>
>> 
>> 										Existing static DH key pair: x, [ID_R =] g^x
>> 
>> 			R1: ID_R
>> 			<------------------------------------
>> 
>> Existing static DH key pair: y, [ID_I =] g^y
>> DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input
>> Derive master key from DH: k
>> Draw random secret: s_I
>> 
>> 			I2: ID_I, ECR(k, s_I), CMAC(k, I2)
>> 			------------------------------------>
>> 
>> 										DH DEX KEYMAT*: Derived using g^{xy}, salt and peer info as input
>> 										Derive master key from DH: k
>> 										Verify CMAC(k, I2)
>> 										s_I = DCR(k, s_I)
>> 										Draw random secret: s_R
>> 										Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I | s_R as input
>> 
>> 			R2: PK, ECR(k, s_R), CMAC(k, R2)
>> 			<------------------------------------
>> 
>> Verify CMAC(k, R2)
>> s_I = DCR(k, s_I)
>> Pair-wise key**: Derived using DH DEX KEYMAT* generation function on s_I | s_R as input
>> 
>> 
>> * Section 6.3 of draft-moskowitz-hip-rg-dex-02 explains how key material generation works in detail.
>> ** The pair-wise key is used in DEX for the payload protection protocol.
>> 
>> ECR and DCR denote encryption and decryption functions (preferably AES in the CoRE scenario) with the symmetric key as first input and the plain-text as second input parameter. Furthermore, the DEX draft does not provide signing functionality at the moment. However, I believe that this can still be changed according to the needs of the community.
>> 
>> I have left out performance optimizations and DoS protection mechanisms in my descriptions (e.g. R1 pre-creation and puzzle) for the sake of clarity. I hope that this description provides the kind of information you are looking for. Note that PK-based authentication and DH key derivation are two separate mechanisms with HIP and are not integrated in a similar way as for HMQV.
>> 
>> Please let me know, if you need more specific information on one of the mechanisms or the packet exchange I talked about above.
>> 
>> BR,
>> René
>> 
>> 
>> 
>>>> I am sending this to the list, since Carsten Bormann is right: the group as a whole would benefit from technical discussions.
>>>> 
>>> Sure.
>>> 
>>> Best regards,
>>> 
>>> Tobias
>>> 
>>> 
>>> 
>>>> Best regards, Rene
>>>> 
>>>> On 20/10/2010 4:35 PM, Rene Struik wrote:
>>>>> Hi Tobias:
>>>>> 
>>>>> If the device's public key and the CA's signature verification key are similar mathematical objects (e.g., both are on the same elliptic curve), then the crypto real estate to perform certificate self-tests can be made to reuse that used to perform key computations with an authenticated key agreement scheme that uses certs. Obviously, this would require the device to have access to an authentic copy of the CA's signature verification key. If the CA's public key is not available, it cannot check its own cert an alternative authentic channel has to be established between the device and an external party who attests to the authenticity of the cert. This being said, I do not know of practical scenarios where the latter limitation arises (usually, one does not accept any cert for which one does not already have a bootstrapped [or not] root CA key).
>>>>> 
>>>>> It seems somewhat dangerous to use certs to bind arbitrary strings to public keys if the semantics of that string is not well-understood or can be defined at will be another process. After all, if the string is StrA and semantics of one application defines this as "temperature sensor A", while another application defines this as "thermometer B", confusion may arise: does (StrA, PublicKey) relate to some physical device A or some physical device B? Not sure how this can be avoided if one does not stipulate that for any semantics one may define, the mapping String -->  Globally Unique Device Id is an injection. Intuitively, this seems to suggest that each string contains an object that is 1-1 mappable to this globally unique device id.
>>>>> 
>>>>> Best regards, Rene
>>>>> 
>>>>> 
>>>>> 
>>>>> On 20/10/2010 2:37 PM, Tobias Heer wrote:
>>>>>> Hi Rene,
>>>>>> 
>>>>>> Am 20.10.2010 um 17:58 schrieb Rene Struik:
>>>>>> 
>>>>>>> Hi Tobias:
>>>>>>> 
>>>>>>> No worries - I am just curious to see how HIP fits in with ubiquitous networks of smart objects, why one would care about the protocol, and which use cases are enabled. Depending the outcome hereof, it may be worth pointing to in IETF drafts etc.
>>>>>>> 
>>>>>>> Some brief comments below (enclosed by RS>>   and<<RS).
>>>>>>> 
>>>>>>> Best regards, Rene
>>>>>>> 
>>>>>>> On 20/10/2010 11:31 AM, Tobias Heer wrote:
>>>>>>>> Hi Rene,
>>>>>>>> 
>>>>>>>> First: thanks for your feedback. [snip(RS)]. I'll respond to the quick questions immediately and will come back with a more detailed and better specified description in a couple of days. Actually René Hummen might respond instead of me.
>>>>>>>> 
>>>>>>>> Am 20.10.2010 um 16:59 schrieb Rene Struik:
>>>>>>>> 
>>>>>>>>> Hi Tobias, Zhen:
>>>>>>>>> 
>>>>>>>>> I would be indebted if you could provide some feedback on my email as of Tuesday last week (October 12, 2010, 12:23pm EDT - - cf. below).
>>>>>>>>> 
>>>>>>>>> Best regards, Rene
>>>>>>>>> 
>>>>>>>>> On 12/10/2010 12:23 PM, Rene Struik wrote:
>>>>>>>>>> Hi Tobias:
>>>>>>>>>> 
>>>>>>>>>> Thanks for your note.
>>>>>>>>>> 
>>>>>>>>>> Does your "ascii art" description, Step 1)-3) allow the scenario, where (a) one assigns a node id and imprints this (e.g., blowing fuse during chip testing);
>>>>>>>>>> (b) has a node generating its own long-term public/private key pair and outputting its node id and public key (e.g., during chip testing -- this would
>>>>>>>>>> correspond to registering a public key with an RA); (c) have CA create a certificate in different process and return this value at later production/
>>>>>>>>>> personalization stage?
>>>>>>>> a) yes it would
>>>>>>>> b) yes, the node could generate the static DH key by itself and acquire a certificate for this key (e.g., at deployment time)
>>>>>>>> c) I am not completely sure what you mean with "different process" and "return" however, I can outline the possible flexibility that one would have:
>>>>>>>> 
>>>>>>> RS>>
>>>>>>> Setting would be where one would register a pair (Device Id, Public key) during production, ship a database of these pairs to a CA, have the latter generating a certificate for (Device Id, Public key) pairs of its choosing and tie this to associated keying material (such as policy field, validity period, and the-like). Certificates themselves could then find a way back to a device via any other communication channel (does not require online/inline involvement of CA and could, e.g., by provided when personalized in a BestBuy shop, using a BestBuy CA (note that BestBuy CA would then have to relie on the RA used during production - the one that collected the database).
>>>>>>> <<RS
>>>>>>>> (I am taking about DEX now, not HIP BEX)
>>>>>>>> 
>>>>>>>> i)   The static DH key can either be node-generated or imprinted by some entity (in a secure environment)
>>>>>>>> ii)  The certificate can either be imprinted when the node is manufactured or it can be imprinted later (again, in a secure environment)
>>>>>>> RS>>
>>>>>>> Not sure why imprinting of certificate (authorization of state change aside) would need to be done in secured environment in general, since this is public piece of information.
>>>>>>> <<RS
>>>>>> Sure, the information is public but nodes that cannot verify their own certificate (I do not assume that all nodes are able to verify digital signatures. However, I am not sure if it is useful to assume that a host supports ECDH but not ECDSA) might accept an invalid certificate and could, from that moment on, not authenticate towards a legitimate host anymore. The secure environment is not needed if a) a node can verify its own certificate or b) if the node can verify the identity of the device that imprints the certificate.
>>>>>> 
>>>>>>>> iii) The certificate could be renewed at any time (provided there is a secure mechanism for that)
>>>>>>>> iv)  The DH public key could be renewed as well (at any time), however, a node would require a new certificate, authenticating the new DH key then
>>>>>>>> 
>>>>>>>> For BEX, nodes' identity would be the RSA/DSA/ECDSA key of the node instead of the static DH public key. Hence, the ephemeral DH key would change more often while the ECDSA public key would be in the certificate.
>>>>>>>> 
>>>>>>> RS>>
>>>>>>> I still have some trouble understanding how identifying nodes by their public key is going to satisfy use case scenarios where one may have changes to the public key, different certificates, and the-like. Please note that the objective of certificates is to provide for a secure binding between a device's id and its private key (via the corresponding public key), thus freeing one to just use device ids -- after all, certificate processing would then yield the corresponding public key(s) purportedly owned by that device.
>>>>>>> <<RS
>>>>>> The certificate would bind a string to the public key (static DH or RSA/DSA/ECDSA). The string would be used by layers above HIP. HIP maps the string to the static public key of the peer in the BEX by using the certificate that the peer provides. A device is therefore identified by a string not a public key (as in vanilla HIP).
>>>>>> 
>>>>>>>>>> Right now, from Section 4.1.3 of draft-ietf-hip-rfc5201-bis-02, I get the impression that HIP does execute an authenticated DH key agreement scheme. If so,
>>>>>>>>>> this makes me wonder how HIP differentiates from protocols, such as ECMQV and, e.g., HMQV, which are all not that much more expensive than ECDH. If the
>>>>>>>>>> difference is in the "puzzle" element, couldn't one just add something similar to a well-known authenticated scheme that is already standardized with, e.g.,
>>>>>>>>>> NIST?
>>>>>>>> I'll let René Hummen respond to this question.
>>>>>>>> 
>>>>>>> RS>>
>>>>>>> Sure - looking forward to this. This would be easy to compare, once one has succinct description of the cryptographic aspects of the protocol (so that, e.g., one can count the number of scalar point multiplications involved, etc.).
>>>>>>> <<RS
>>>>>>>>>> As to forward secrecy: reason to include this is that many sensor-type nodes can be expected to be physically unprotected (e.g., screwed on a street lamp
>>>>>>>>>> post, on a garage roof, etc.) and, therefore, may be more vulnerable to device compromise over time (esp. since one cannot expect all nodes to be tamper
>>>>>>>>>> resistant or tamper evident). By virtue of forward secrecy, compromise over time does not compromise the whole device's history, but only the current set of
>>>>>>>>>> symmetric keys (note: I make some shortcuts in my reasoning on key management here). Admittedly, my list of security properties is based on "desired"
>>>>>>>>>> functionality and does not exclude functionality that may require, e.g., public-key crypto constructs. However, from a user's perspective, the only thing that
>>>>>>>>>> matters is features and not what is "under the hood", as long as that is not cost-prohibitive (which I contend it is not -- cf., e.g., Section 3.2 of
>>>>>>>>>> draft-struik-6lowapp-security-considerations-00). (BTW - All other desired security properties I listed have an underlying rationale.)
>>>>>>>> I am still somewhat unsure about cost and capabilities of the targeted devices. Depending on who you talk to, people seem to expect sensors that are capable of ECC crypto, barely capable or not capable at all.
>>>>>>>> Are there minimal hardware specs for target devices?
>>>>>>>> 
>>>>>>> RS>>
>>>>>>> Almost all 802.15.4-based modules have hardware support for AES-128 (in forward mode). Since the MAC layer requires error detection using CRC-16 linear feedback shift regsiter circuits (which is a no brainer) and since, e.g., elliptic curves over binary extension fields can be realized using shift registers that are of order of magnitude anything up to 256 registers, I do not see a problem for hardware support here (once implemented in large scale environments).
>>>>>>> 
>>>>>>> Source: http://2010.eccworkshop.org/
>>>>>>> Junfeng Fan<http://homes.esat.kuleuven.be/%7Ejfan/>(K.U.Leuven, Belgium)
>>>>>>> /ECC on constrained devices/
>>>>>>> The embedded security community has been looking at the ECC ever since it was introduced. Hardware designers are now challenged by limited area (<15k Gates), low power budget (<100uw) and sophisticated physical attacks. This talk will report the state-of-the-art ECC implementations for ultra-constrained devices. We take a passive RFID tag as our potential target. We will discuss the known techniques to realize ECC on such kind of devices, and what are the challenges we face now and in the near future.
>>>>>>> <<RS
>>>>>> Impressive. I'll certainly give it a closer look.
>>>>>> 
>>>>>> Tobias
>>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> email: [email-masked]
>>>> Skype: rstruik
>>>> cell: +1 (647) 867-5658
>>>> USA Google voice: +1 (415) 690-7363
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>>> Chair of Communication and Distributed Systems - comsys
>>> RWTH Aachen University, Germany
>>> tel: +49 241 80 207 76
>>> web: http://ds.cs.rwth-aachen.de/members/heer
>>> blog: http://dtobi.wordpress.com/
>>> card: http://card.ly/dtobi
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Dipl.-Inform. Rene Hummen, Ph.D. Student
>> Chair of Communication and Distributed Systems
>> RWTH Aachen University, Germany
>> tel: +49 241 80 20772
>> web: http://ds.rwth-aachen.de/members/hummen
>> 
> 
> 
> -- 
> email: [email-masked]
> Skype: rstruik
> cell: +1 (647) 867-5658
> USA Google voice: +1 (415) 690-7363
> 

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen