Re: [smartpower-interest] Smart Grid Architecture Committee meeting 17 February

[Zach Shelby <[e-mail]>]

Hi,

On Feb 19, 2010, at 19:29 , Russ Housley wrote:

>> It would be nice if [...] the architecture could specify the use of "suite b
>> cryptographic standards". For those that don't know what that means, it
>> refers to the use of elliptic curve public key cryptography without the
>> IPR considerations that have crippled the industry's ability to use it.
> 
> Suite B is composed of algorithms that are publicly specified, and it is
> defined here: http://www.nsa.gov/ia/programs/suiteb_cryptography.
> 
> Suite B includes:
> 
> Encryption:  AES with 128- and 256-bit keys

Good to hear this. AES-128 is suitable for at least IEEE 802.15.4 based 6LoWPAN networks, as these radio chips include an AES-128 hardware engine which can often be accessed for general purposes as well. 

> 
> Key Exchange: Elliptic Curve One-Pass Diffie Hellman (called ECDH) using
> the curves with 256- and 384-bit prime moduli
> 
> Digital Signature: Elliptic Curve Digital Signature Algorithm (called
> ECDSA) using the curves with 256- and 384-bit prime moduli)
> 
> Hashing: SHA-256 and SHA-384
> 
> The smaller size in each of these choices seems quite reasonable for
> Smart Grid.
> 
> There are intellectual property issues with Elliptic Curve Cryptography
> (ECC), but McGrew seems to have found at least one way to implement
> these algorithms that avoids the known patents.  See:
> http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01
> 
>> [...] The lack of a key management
>> infrastructure is a problem, which I would entertain useful proposals for.
> 
> As a starting point for this discussion, can we leverage the work done
> by CableLabs and the WiMAX Forum.  Devices that follow the
> specifications from these groups ship with an embedded private key and a
> certificate.  This is not the complete answer, but it allows anyone to
> authenticate the device.  At some point prior to installation, the
> device still needs to be told some things about the network that it will
> be connected.  This might be as simple as the insertion of some
> configuration data that includes a trust anchor to validate certificates
> from the utility.

This is also a big problem for constrained networks and device such as we see in 6LoWPAN (http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp). Luckily, it is an important topic in a new proposed working group called Constrained RESTful Environments (CoRE) which includes work items related to security bootstrapping and cooperation with the security area on finding suitable security methods. This is being done in cooperation with ZigBee Smart Energy 2.0 which is IPv6 based. Here are a couple related early drafts for those interested:

http://tools.ietf.org/html/draft-struik-6lowapp-security-considerations
http://www.ietf.org/id/draft-oflynn-6lowapp-bootstrapping-00.txt

Zach


-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.