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

[Russ Housley <[e-mail]>]

Fred:

I have a few comments about IPv6 and security.

> I am forwarding in case you folks have not seen this. It is the proposed
> IP architecture from NERC, which is a US regulatory body.
> 
> One important statement it makes is:
> 
>> A final note is that this document will not make the distinction
>> between IP version 4 or version 6 for the purpose of analysis or
>> standardization.  The point is simply to support IP with the version
>> number left to be an implementation detail determined by the utility
>> or service provider that would install the AMI network.  That being
>> said, any competent network planner can easily do the math - many
>> investor-owned utilities have literally millions of electric meters
>> installed (a distinct challenge in a version 4 environment), with this
>> "volume problem" being compounded by the presence of other devices
>> including some quantity of electric vehicles as potential roaming
>> users in the future.  That means the utility would either have to use
>> IPv4 very judiciously and replicate private IP space over and over
>> again, or move to IPv6 and address a greater number of devices uniquely.
> 
> This is not as strong a statement re IPv6 as the IETF and ARIN have
> proposed, but is at least a sensible one in the near term.

This allows NAT upon NAT.  I would prefer NERC to more strongly advocate
IPv6.  NERC does not even say that IPv6 is the long-term solution.  I
wish they had gone that far.

> The architecture doesn't say a lot about security, but does say this:
> 
>> The C12.22 protocol also includes AES-128 security mechanisms.
>> Additional IP transport security protocols may be provided to enhance
>> and preserve the upper layer security provisions but not as a
>> substitute of such.
> 
> Personally, I think that's an inadequate statement. The key issues are
> in identification, authentication, authorization, and confidentiality
> where appropriate.

I agree that these are the right security services to include as long as
you consider access control to be part of authorization.


> 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

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.

Russ