"Vin McLellan" <[EMAIL PROTECTED]> writes: > The Wheelers' comments -- a response to my claim that RSA's fabled > crypto savvy influenced the design of the SecurID OTP token -- were > inaccurate and misleading. > > I've been using the Wheeler's posts to educate and frighten my clients > for years, so I'm sure the error is unintentional, perhaps even caused > by some lack of clarity in my earlier post. Since the Wheelers' > industrial history archive is likely to be referred to often in the > years to come, however, I did not want even this brief aside to stand > uncorrected. > > It should surprise no one, certainly not Lynn Wheeler, that after the > 1996 merger of SDI and RSADSI, RSA's new team of cryptographers and > crypto engineers began to urge a completely redesign of the original > SecurID system around stronger (128-bit) cryptosystems. > > (The RSADSI folks were not unfamiliar with the SecurID. The SecurID > client/server protocol had been designed around a proprietary hash > developed for SDI by Ron Rivest, the "R" of RSA. After the merger, > RSA's crypto engineers pushed to harden the SecurID system -- which > already had a huge installed base, and dominated its market niche -- > against new threats from the ubiquitous network and the Web. I was then > a consultant to SDI, as I am now to RSA -- a bit of the proverbial fly > on the wall.
this is along the lines of the old silicon valley joke about there actually only being 200 people in the industry ... it looked like more, because the same people just kept moving around. i was mainly referring to RSA public key cryptography ... which most people identify RSA with ... differentiated from non-RSA public key infrastructure used by SecureID. in that time-frame, there were also a lot of stuff going on around RSA public key cryptography and the use of RSA digital signature in hardware tokens for authentication ... types of stuff you find in SSL, the various PKCS standards ... including work on PKCS#11 that RSA, Netscape, etc was pushing for RSA (public key digital signature) authentication smartcards ... as opposed to secureid cards (there were some PKCS#11 meetings with the various participants at the toll house in los gatos). also, much of the differential power analysis is heavily oriented towards RSA public key smartcards (attacks on rsa private key) one of the issues in heavy push for RSA public key digital signatures for smartcard authentication ... was that the alternative was FIPS186 digital signature which required a reliably random number be generated as part of the digital signature calculation. most of the hardware token chips from the period not only had issues with differential power analysis (attacker being able to obtain lots of information about RSA private key during RSA digital signature and/or encryption operation) but had dismal random number capability. One extensive study of most chips from the period ... involving power-off/power-on generate random number ... repeated 65k times, found nearly all chips having something like 30 percent of the time, there was a repeated random number. i've frequently contended one of the reasonse there was extensive standards work on RSA digital signature authentication during the period ... was because the alternative gov. standard FIPS-186 digital signature (for strong authentication) was heavily dependent on random number generation during the digital signature calculation process ... that made it nearly useless in hardware tokens of the period (aka poor random number generation could reveal more about FIPS-186 private key than differential power analysis was revealing about RSA private key). However, for that generation of RSA public key tokens, the common practice was to pre-personalize the tokens by using an external box ... with a reliable random number generation source ... to generate the RSA public/private key pair and inject the RSA private key into the token (since reliable random number generator is also required during the key generation process). In the late 90s, you started to see a combination of things ... FIPS186-2 was upgraded to included ECDSA ... which has radically different private key vulnerability to differential power analysis, (especially compared to RSA), chips that had acceptable hardware random number characteristics (eliminating private key exposure vulnerability because of poor random number generation), and sophisticated power use management that included injected random power cycles(as additional countermeausre to differential power analysis). I joke during the period that i could take a $500 milspec part, cost reduce it by two orders of magnitude and at the same time, make it more secure. Some of the smartcard endevors got into this vicious negative feedback loop, the cards were more expensive than a single purpose could justify, so add more features, which increased the cost, which required adding more features to justify the cost, which increased the cost. an alternative approach was to aggresively cost reduce all the components ... throwing out everything not required for authentication. part of the issue around extraneous features is that they can contribute to insecurity. the advent of chips with higher quality random number generation also it made it feasable to start during key generation on the chip (eliminating the pre-personalizing step where keys are generated by external boxes and injected into the chip). however, there is frequently still a strong tendency to get into the negative feedback cycle of increasing the features to justify the cost, which increases the cost (and complexity) , which requires even more features to justify the cost. one of the downside of this other approach to authentication hardware tokens is that they require an explicit hardware interface between the environment and the hardware token. securid had a lower per seat entry since existing keyboard and screen could be utilized. that may be in the process of changing with the advent of wireless technologies that can be used for a variety of different purposes ... including wireless authentication token. the upside of the digital signature tokens is that they require a much simpler backend infrastructure operation (once the downside of the interfacing has been overcome). it is possible to take the single/same token and register the token's public key in a large variety of different domains and environments ... resulting in a single token authenticator ... this is the person-centric approach to authentication contrasted with the institutional-centric approach that effectively requires a unique token for every different security domain. I once went around to most of the booths at a smartcard conference ... joking that if the current (institutional centric) hardware token paradigm ever took off ... people would be replacing having to keep track of hundreds of passwords with having to keep track of hundreds of hardware tokens. random past posts mentiong the person/institution centric authentication subject http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA) http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb??? http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards http://www.garlic.com/~lynn/2005g.html#57 Security via hardware? http://www.garlic.com/~lynn/2005m.html#37 public key authentication http://www.garlic.com/~lynn/2005p.html#6 Innovative password security http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
