[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: On shared keys (was RE: SOI: identity protection and DOS)



Message David, I have been trying to convince people that RSA public operation provides no lear scalability adavantage over symmetric key. So let me do a orange to range comparison again using a full mesh and a hub-spoke case. I am only illing to agree with your saying that RSA is better in scalability if uch comparison proves it. Assumption: 1) No CA 2) RSA key pair generated in device. Symmetric key generated in server. 3) Server needs to deliver either public key or symmetric ey. case 1: Full mesh: N*(N-1)/2 unnels   RSA   PSK   1) total number of keys  N key pair   N*(N-1)/2 PSK 2) key generation cost   high low 3) number of key elivery N*(N-1) N*(N-1) 4) key storage on the box 1 private key -1 PSK N public key 5) authentication calculation high    ow cost 6) key on server N public key   N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels   RSA   PSK   1) total number of keys   N key pair   N-1 PSK 2) key generation cost   high   low 3) number of key elivery (N-1)*2 (N-1)*2 4) key storage on the box hub N public ey N-1 PSK spoke     2 public key   1 PSK 5) authentication calculation high    ow cost 6) key on server N public key   N-1 (usually not stored) So if you are only considering the total number of keys, RSA wins. If you ook at overall operation cost, the comparison speaks itself. nfortunately, there is a lack of scalability adavantage for RSA. >-----Original Message----- >From: avid chen [mailto:ietf_davidchen@hotmail.com] >Sent: Monday, December 3, 2001 12:49 PM >To: Wang, Cliff; Sandy Harris; 'IPsec WG' >Subject: Re: On shared keys (was RE: SOI: identity rotection and DOS) > >Cliff, >My comment is in lue. > >In addition, >The RSA public/private key is better han symmetric key for >the key management and scalability easures with slight >advantage of security that the ublic key can be 'public' as long >as the id/public-key binding is ntact in apposing to >the symmetric key has to defend both. > >--- David > > >----- Original Message ----- >From: "Wang, Cliff" <<3d.htm>CWang@smartpipes.<3d.htm>com> >To: "'david chen'" <<3d.htm>ietf_davidchen@hotmail.<3d.htm>com>; "Wang, Cliff" <<3d.htm>CWang@smartpipes.<3d.htm>com>; "Sandy Harris" <<3d.htm>sandy@storm.ca>; 'IPsec WG'" <<3d.htm>ipsec@lists.tislabs.<3d.htm>com> >Sent: Saturday, December 01, 2001 :33 PM >Subject: RE: On shared keys (was RE: OI: identity protection and DOS) > > > Thanks for the discussion and ee my comments in line. > > > > -----Original Message----- > > rom: david chen [mailto:ietf_davidchen@hotmail.com] > > Sent: Friday, ovember 30, 2001 11:52 PM > > To: Wang, Cliff; Sandy Harris; 'IPsec G' > > Subject: Re: On shared keys (was RE: SOI: identity protection and OS) > > > > [david] > > Cliff, > > Let's agree that the re-shared symmetric key will only *intended* used by > > two devices. Let's ook at a 5 devices network and a central keys deposit > > server. For ey management purpose, both the pre-shared RSA public keys and > > he symmetic keys will be in a server. (Don't see any scalable odel other > > than this) > > > > For a fully meshed ommunication model among these 5 devices: > > 1) the symmetric keys ase: > > The server have to store 10 = (5*4)/2 s. keys. and keep track of which link > > associate to which key. Before device_1 communicates ith device_2, these > > transactions have to happen: the sk_12 ill be sent from server to device_1 > > and device_2 through out-of-band ecured channel. (well, this dynamic model > > is scalable otherwise if he 10 keys pre-loaed on each of the 5 devices; it > > will be difficult hen a device join-in...) After the full mesh is reached, > > each evice will have 4 Skeys. > > > > 2) the RSA keys case: > > The erver have to strore 5 public keys and don't care about link info., but > > ave to associate device to its public key. Before device_1 ommunicates > > with device_2, these transactions have to happen: the pk_1 is ent to > > device_2 from server and the pk_2 is sent to device_1 rough out-of-band > > secured channel. After the full mesh is reached, ach device will have 4 > > public keys and its own private eys. > > > > Observation: > > 1. The symmetric key management model hows that for a single skey, there > > are 3 parties know it. The 2 devices nd the server. Clearly, get the skeys > > in the server is most ffective to break entire mesh. In contrast to the > > symmetric key, get he public-keys in the RA does not break any secure link. > > therefore, you can let 3rd party manage this server "RA", as long as it > > uarantees id/public-key bindings) > > > > [cliff] agree. In this case, server break-in is a very serious security > > breach and it can eopardize the whole operation. When such an event > > happens, even though the ttacker can't take advantage of the public key, he > > can do enough amage to other things such as billing, device configuration, > > tc. > > > > In contrast with the server break-in case, a device ompromise is much more > > likely. Let's take a look at this case. In a full esh setup, PSK or > > pre-shared RSA suffers the same degree, say 4 artners are compromised. > > However, in a hub-spoke setting where only 4 unnels exists, if a spoke is > > compromised, only the link to the hub s compromised when PSK is used. If > > pre-shared RSA is used, then otentially communication to both hub and the > > rest 3 spoke an be compromised. So in that case, pre-shared RSA is worse > > than a pre-shared key. > > >In the case of ub-spoke topology (not full-mesh) and >pre-shared RSA ublic key are used, >if a spoke is ompromised, only the link to the hub is compromised, >don't see how the est of 3 spokes are compromised. >Note that, In bove example, >each device in the ub-spoke only stores its own private key and >others' public keys. The server in above exmample is part of "out-of-band" >communication model. It is a reasonable way for key management and >not part of 'security link' topology (full mesh, start, bus, and any secured' comm. topology) >in the articipated devices. >(It is possible that the server is a person :-) > > > [david] > > 2. The number of keys in the server is clearly more or symmetric keys. In > > addition, it has to keep track of 'link-id'/key pair which is more difficult > > than that of device-id' in the case of public keys. > > [cliff] Although the public key may e cached in the server, there is no > > need to save the PSK for a tunnel t the server, since they have been > > delivered to both tunnel ends. f a new PSK is needed, just generate it and > > push it out to both ends gain. However, the server key storage seems to be > > an implementation ssue. > > > > > > > > --- David > > P.S. I gree that when a device been tampered, all the established secured > > link o this device are broken for either symmetric or asymmetric keys are > > sed. > > > > > > > > > > ----- Original essage ----- > > From: "Wang, Cliff" <<3d.htm>CWang@smartpipes.com> > > To: "'david chen'" <<3d.htm>ietf_davidchen@hotmail.com>; "Sandy Harris" > > <<3d.htm>sandy@storm.ca>; 'IPsec WG'" <<3d.htm>ipsec@lists.tislabs.com> > > Sent: Friday, November 30, 2001 2:49 PM > > Subject: RE: On hared keys (was RE: SOI: identity protection and DOS) > > > > > >  This analysis is seriously flawed: > > > 1) SPSK or group re-shared key per box is a bad idea. No security > > conscious > > > people ill adopt this. Because of this serious flaw in assumption, > > > ll security level comparison are meaningless. > > > 2) Once an ttacker compromise a box, he has access to either private > > > ey > > or > > > the pre-shared key. > > > Any communication ith the box's partners are compromised, whether > > > using > > KI > > > or PSK for IKE authentication. Where is the 200% risk come rom? > > > 3) why each device needs to have 499 public keys? They are contained > > > in > > each > > > box's cert and elivered as part of IKE exchange. > > > > > > -----Original Message----- > > > From: david chen [mailto:ietf_davidchen@hotmail.com] > > > Sent: Friday, ovember 30, 2001 1:15 PM > > > To: Sandy Harris; 'IPsec WG' > > > ubject: Re: On shared keys (was RE: SOI: identity protection and DOS) > >  > > > > > > Here is my observation: > >  > > > The RSA puliblic/private key (RSA key) is better than ymmetric > > > pre-shared key (SPSK) in the following way: Suppose both the RSA ey > > > and SPSK all > > using > > > centerally anaged server in a domain and further assume that the SPSK > > > is ne for each device (not one for each pair of device). Let's say > > > here are 500 devices in this domain: Then there will be 500 keys or > > > SPSK so is RSA keys. Each device will either have 499 public keys r > > > 499 SPSKs. Given the key management (add/delete/remove) are *almost* > > > equal, the SPSK has a not ignorable drawback han RSA Key structure: > > > To break RSA key, attacker has > > o > > > break into the device that hold the private key or break into he > > > device that itself is the victim of MIM attack. The device has o > > > responsible for its own security. (Given the real world that he > > > security of a device are not created equal, this is a easonable > > > requirement) > > > > > > On the other hand, to reak a SPSK, the attacker can choose any of the > > > 500 devices to reakin. The risk is much higher for a device due to it > > > demand ll other participated devices have the same security level. > >  > > > Sure, the SPSK can increase the number of keys that limited the key o > > only > > > two parties (and increase the complexicity of the ey management) but > > still > > > it is 200% risk more than SA key due to it demands the same level of > > > security level on peer. > > > > > > > > > --- David > >  > > > > > > > > > ----- Original Message ----- > >  From: "Sandy Harris" <<3d.htm>sandy@storm.ca> > > > To: "'IPsec WG'" <<3d.htm>ipsec@lists.tislabs.com> > > > Sent: Friday, November 30, 2001 10:10 M > > > Subject: Re: On shared keys (was RE: SOI: identity protection and OS) > > > > > > > > > > Alex Alten wrote: > > > > > > > > > I will re-iterate my position. If a etwork security system is > > > > > properly designed then ither Public Key or Symmetric/Private Key > > > > > cryptography will ork fine in establishing trust. > > > > > > > > So ar, so good. > > > > > > > > > I furthermore claim hat Symmetric/Private Key cryptography will > > > > > scale o great numbers of users > > > > > > > > Sorry, but this s nonsense. The classic problem with symmetric > > > > crypto s key management. It neither scales well nor works well > > > > across > > > administrative > > > > oundaries. > > > > > > > > Consider n sites which all want to communicate.> > > > > > > > For symmetric ciphers, you need n*(n-1)/2 nique keys, each of which > > > > is known to exactly two players nd none of the others. Moreover, > > > > you have to communicate hose keys securely to the second player in > > > > each case, and hen keep it secure on both systems. > > > > > > > > With ublic key, you need only n key pairs. There is no need to > > > communicate > > > > keys securely; the system is designed o work even if the enemy > > > > knows the public keys. Nor do you ave to manage security for > > > > multiple keys, or keep track of ho each key is shared with. You > > > > just need to keep your rivate key secure, not shared with anyone. > > > > > > > > f course you can build a kerberos-like system using symmetric > > >  ciphers that has many of the advantages of public key. Using a > > >  central key server reduces the number of keys to n lient-to-server > > > > keys and may simplify management. However, I doubt such > > > > centralised model is appropriate for Internet infrastructure. > > > > > > > > > and I use he bank ATM secure network using DES as an excellent > > > > > xample. ... > > > > > > > > I think that's an irrelevant xample. A tightly controlled single > > > > purpose erminal-to-mainframe network under a single administrative > > > > authority ears no useful resemblanmce to the Internet. Someone gave > > > > a ood detailed analysis earlier in the thread. You should re-read > >  > it. > > > > > > > > > As far as I'm concerned his should be the end of the discussion > > > > > > >  I agree, but for opposite reasons. > > > > > > > >  about whether or not Symmetric/Private Key cryptography can cale > > > > > to large numbers of users in an efficient, easy to use by ordinary > > > > > people, inexpensive to implement anner and interoperable between > > > > > devices made by ifferent manufacturers and maintained by > > > > > different organizations. It has been done for the past 20 years y > > what > > > is > > > > > probably the most uccessful world-wide commercial networked > > > > > ecurity > > > system. > > > > > > > > > > Anyone who till claims that Public Key is superior to > > > > > Symmetric/Private > > > Key > > > > > ryptography, or that it is the only way to scale, is a *damn > > > > > ool* and > > > should > > > > > be treated as uch. > > > > > > > > How about "obviously superior for some urposes, including most key > > > > distribution applications" and almost always the best way to build > > > > scalable ystems"? > > > > > > > > Methinks you'll consider me a fool. I heartily eturn the sentiment. > > > > > > > > > > > >
Follow-Ups: