[smartpower-interest] [Fwd: Re: NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009]

[Ed Jankiewicz <[e-mail]>]

FYI some support I posted to NIST based on Fred's comments

-------- Original Message --------
Subject: 	Re: NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009
Date: 	Wed, 17 Feb 2010 14:44:50 -0500
From: 	Ed Jankiewicz <[e-mail]>
To: 	[e-mail]
CC: 	Fred Baker <[e-mail]>
References: 
<[e-mail]> 
<[e-mail]> 
<[e-mail]>



As an observer here, let me strongly state my concurrence with Fred 
Baker's two main points

1.  given the costs to roll out an IP network with constrained and 
widely distributed elements, it would be highly irresponsible to do so 
with IPv4 at what is certainly the 11th hour of its existence.  
Utilities may not be able to obtain sufficient IPv4 space today to roll 
out such a network, and by 2012 it is almost certain that they will not 
be able to get any large allocations.  The US DoD and civilian agencies 
have mandated that ALL acquisitions of network equipment MUST be IPv6 
capable (currently effective now for DoD, effective July 2010 for 
civilian agencies).  In my personal opinion, smart grid should be IPv6 
by design, with any initial implementations based on IPv4 being the 
exception, and requiring some kind of waiver, with a stated plan to 
convert to IPv6 ASAP.  IPv4 should be considered for use only where IPv6 
is not possible (i.e. existing implementations not amenable to software 
upgrade) and should only be used as a fall-back for any new 
implementation. 

2.  Security issues, in particular authentication, are fundamental and 
should be considered from the earliest stages as non-negotiable.  
Scalable and manageable key distribution is essential to ubiquitous 
implementation of any protection scheme.  I personally agree with Fred's 
points on the intractability of almost anything but public key 
cryptography given the scale of this problem space - very many 
distributed sensor/actuators in the network under central control, where 
authentication is an absolute requirement.  Public key exchange will 
minimize operational complexity and enable future growth of the network.

It is much easier to grant "temporary" permission to operate at reduced 
levels (e.g. IPv4, shared secret cryptography) than it is to go back 
later and impose "new" requirements on legacy implementations.  If this 
discussion is about establishing standards for the future of smartgrid 
technology, they should be forward-looking and based on the best 
published standards, rather than settling for standards that are already 
in "sunset" mode.

Ed Jankiewicz
speaking as an individual

On 2/17/2010 12:11 PM, Fred Baker wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> oops - forgot to actually sign it :-)
>
> Let me follow up on my comment regarding public key cryptography. This 
> is in case someone missed the thrust of my comment operationally.
>
> Symmetric key crypto technologies are technologies in which both 
> sender and receiver of a message have a shared key; if I tell you for 
> example that I will encrypt a message by changing all of the zeroes to 
> ones and all the ones to zeroes (silly, yes), you can apply the same 
> rule and derive the original. AES and DES are symmetric key 
> technologies that actually have some security value. But they also 
> imply that pairs of systems share keys, which means that a given 
> system that talks with a long list of others has a long list of keys 
> to choose from, and we have to communicate keys securely.
>
> Asymmetric key crypto technologies are for some reason not usually 
> called that; they are called "public key". In this kind of a system 
> each system develops a pair of keys, one called a "private" key and 
> one called a "public" key. A message encrypted in the public key can 
> only be decrypted using the private key and vice versa. In this case, 
> each communicating system needs exactly one key pair, and the public 
> key can be posted on a billboard if one likes. If I want to send a 
> message that any person can verify is from me, I encrypt or sign it 
> using my private key and post my public key; to verify the 
> authenticity of the message, anyone can apply the public key. I have 
> done that with this email, signing it with my private PGP key; if you 
> have PGP software, you can download my public key from pgp.com and do 
> so. If I want to make a message private to you, I would encrypt it 
> using your public key, knowing that only you have your private key and 
> therefore only you can read it. Generally speaking, when using this, 
> people sign with their private key and encrypt using their peer's 
> public key.
>
> In general, I think there is value in a subset (not all) messages 
> exchanged in the smart grid being signed or encrypted. I would suggest 
> that a meter, which is read perhaps every six hours, wants to sign its 
> meter-read message and encrypt it in the public key of the system that 
> needs to consume the data. That preserves the privacy of the consumer 
> of the service that the meter is measuring and ensures that everyone 
> now and forever knows that the meter reading data is in fact what the 
> meter said it was. I would similarly suggest that pricing messages or 
> demand management messages be signed by the utility, so that it is 
> clear that they are what they are. They need not be encrypted. Part of 
> that is the question of a chain of authority; while many things in my 
> home can be turned on or off at will, some may be life-supporting or 
> otherwise need special authorization to control. Even for a light 
> switch, before I toggle its state I will want to know that the person 
> flipping it is not the kid down the street doing the 21st century 
> equivalent of TP'ing his friend's house - or something more sinister. 
> There are quite a variety of other messages in the exchange that need 
> neither be signed nor encrypted, as they simply support the ongoing 
> communication.
>
> On Feb 17, 2010, at 10:08 AM, Fred Baker wrote:
>
>>
>> I have done a quick review on this. I hope you're on the 
>> [e-mail] list; if you are, you have already seen 
>> my comment to that list.
>>
>> I would have preferred that the document made a stronger statement 
>> about IPv6; the current statement will, I fear, result in utilities 
>> trying to push IPv4 usage in the near term, creating a need to 
>> transition from IPv4 to IPv6 in the relatively near future. Utilities 
>> would do better to go straight to IPv6 up front for operational 
>> reasons, as transition is messy and can be expensive if it means 
>> upgrading firmware with a new image that may not fit in the target 
>> memory system. I would hope that the architecture would make clear 
>> that IPv6 support is mandatory in products deployed in the Smart 
>> Grid, even if the utility deploys IPv4 in the near term, to overcome 
>> those issues.
>>
>> I also don't find the statement regarding security adequate. It says 
>> that C12.22's use of AES-128 is fundamental, and overlooks the use of 
>> Suite B technologies that enable IPR-free verifiable public key 
>> authentication, such as one might find in 
>> http://tools.ietf.org/html/draft-mcgrew-fundamental-eccSymmetric key 
>> cryptography has its place, but I think public key cryptography would 
>> be far more scalable. To give you an idea of the implications, with 
>> symmetric key crypto, either every system in a domain uses the same 
>> key (which is not very secure) or every pair of systems shares a key, 
>> which means that central controllers have a key for each meter that 
>> they might speak with. With public key, every system including the 
>> central controller has a single key pair, public and private, and 
>> either encrypts in its own private or its peer's public key depending 
>> on the intent (does this prove that the message came from a given 
>> system or is read by a given system, or both?) or signs using its own 
>> private key. I also didn't see any attention given to the process of 
>> changing keys, which will be an issue. I further see no attention to 
>> threats at the Transport, Network, or Data Link layers. In an IEEE 
>> 802.15.4g network such as suggested by Zigbee, if I wanted to attack 
>> the system, I would either generate a high power radio signal to 
>> drown out communication or intercept/interdict exchanges on the 
>> "wire". I see no attention to those issues.
>>
>> The thing I find most surprising is that it focuses not on TCP/UDP 
>> over IPv4/IPv6, but on the use of the ANSI C12.19 and C12.22 
>> standards, which are an application, and are in the January standards 
>> document downgraded from "mandatory" to "we really aught to think 
>> about these". I frankly think the industry would be better served 
>> with a NetConf exchange of XML objects using an appropriate schema, 
>> perhaps that suggested by OASYS.
>>
>
> http://www.ipinc.net/IPv4.GIF
>
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFLfCHRbjEdbHIsm0MRAv9HAKD8XNcUQHgOH9K5D022LS/n2AJSrwCgjf57
> lv/DaS1agEEuTK/IVeeY8SE=
> =oL1B
> -----END PGP SIGNATURE-----
>
>
>



-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [e-mail]