The MIS department where I work has started using "Secure-ID" cards made by Security Dynamics Inc for access to their MVS systems. After listening to a presentation by marketing droids and technical support from Security Dynamics I had these impressions: The cards are programmed at the factory with a "random" seed. They have an internal clock, and a lithium battery. They use a proprietary encryption algorithm to encrypt the time of day using the internal seed and display it on an LCD display using about 6 or 7 digits. The display updates itself every 60 seconds (this frequency is adjustable when you order the cards) An authenticating host will have the cards seed, as well as the cards "clock offset" (the time the card was seeded, and the clock reset). The user has a 4 digit PIN (personal identification number) known only to the host (and of course written on the back of the card :-). PIN numbers must be unique since they are used to identify the user. At login time, the user is asked to type in her PIN, as well as the number currently displayed on the card. This is checked by the host, and if it's correct the user is authenticated. If used on a regular basis, the authenticating host can detect clock drift and will adjust it's database accordingly. Cards can be used across multiple "realms", but this nessesitates trusting the cards shared key with each host that wants to authenticate that card. The cards are timed to deactivate after some time interval (again, this is an option) the default lifespan is 3 years, they can go as high as 4 or 5, but after that, the battery isn't reliable. You can probably imagine some of the problems with such a system. First and foremost in my opinion, it uses an unknown proprietary algorithm which is a closely guarded company secret known only to them and anyone which a dissasembler. Obviously such an algorithm has never undergone any serious scrutiny. Most respectable researchers (outside of Ft Meade) do not need to disassemble code to find material to write papers on. Second, the cards are programmed at the factory, and the user has no way of reseeding them. The company actually touts the fact that they have all the card info for all customers on file, and will gladly send you encrypted tapes or floppys if you loose you database! Of course they will only talk with one designated contact at your site, and they will only ship materials to that person. In all fairness if your a big client, and you insist, they might be compelled to tell you how to seed the cards, and give you a batch of "raw" cards. When I mentioned how ludicrous it was for us to trust their internal security, they made some lame noises about employees being "bonded". In other words, they have established plausible denyability and are "out of the loop" should your security data be compromised. I was a little furious. Lastly, their expensive. Something on the order of $60/card in quantities of 250 to 500 for cards that last 3 years and change every 60 seconds. Programmable DES devices (used by DEC and others) which employ a challenge response system are about one third as much. I came away from the talk with a bitter taste in my mouth. As I understand it (and please correct me if I'm wrong) they are, at this point, one of the largest companies "crypto card" companies in the world. This is, to say the least, unsettling. If you want more info, they're Colorado office is at: Security Dynamics 5299 DTC Boulevard Suite 500 Englewood, CO 80111 Phone: +1 303 773-6519 brad
At one point, I talked to Security Dynamics, and experienced the same reaction as the original poster. Additionally, I found it ludicrous that the cards were programmed to self-destruct after a period of time, that they keep their encryption scheme so secret (though they'll sell you source code if you fork over sufficient bucks), and that there was no way to reprogram/reset the cards in the field. I also couldn't stomach their "well, you just have to trust us" response to a lot of my objections about it being a closed proprietary system, having them know all of my key data, and not being able to reprogram the cards. I had much better luck with Digital Pathways, and their "SecureNet Key" product. This is a small (about as long and wide as the SecurID card, but about 2.5 times as thick) hand-held authenticator that's meant to go with Digital Pathways' "Data Defender" secure communications front-end, though they sell the SecureNet Keys separately, and they're not very expensive. They use DES, are individually field-programmable, and Digital Pathways is only too happy to give you as much info about them as you want - for free. With the info they gave me, it was no problem towrite code that knows how to use the SecureNet Key. --Pat.
Re: security dynamics One could perform an interesting test with one of these Security Dynamics card. Aim a video camera at the LCD display so that the display takes up the full width of the image. Hook the video signal up to a digitizer board, and recognize the numbers that appear on the face. Spit them out as often as they appear. For someone with all the equipment, this should be a one or two evening hack. Now, if the number changes every minute, that's a little over 10,000 samples in a week, certainly enough to determine if they are using weak random number generation. I'll put the data on the ftp site, should anyone actually do this. Eric
Now, if the number changes every minute, that's a little over 10,000 samples in a week, certainly enough to determine if they are using weak random number generation.
1) not true. I read an article about a pseudorandom number generator which appeared random to every test they used on it. Then they went and did a monte carlo simulation of something based on that prng. Guess what? It wasn't quite random enough. Lesson: it can be *very* hard to determine randomness. 2) The sequence is not random. It is cryptographically pseudorandom. This is very different. 3) A friend who has a significant math background in crypto stuff has seen the Security Dynamics algorithms (under non-disclosure), and says that they're credible. That vouches for their theory. That they insist on programming the cards and keeping the keys themselves, and that they do not allow you to program the cards yourself, is a major problem, no matter how good their math is. Marc
Now, if the number changes every minute, that's a little over 10,000 samples in a week, certainly enough to determine if they are using weak random number generation.
1) not true. I read an article about a pseudorandom number generator which appeared random to every test they used on it. [...] Lesson: it can be *very* hard to determine randomness.
The experiment I was proposing would possibly answer 'yes' to the question "Is the number generation weak?" It would not say how strong it was, or even if it was strong. it would, however, give some lower bound on its strength or else show that it was in fact not very strong at all.
2) The sequence is not random. It is cryptographically pseudorandom. This is very different.
Since we are talking about a device in which a sequence is duplicated on two ends, I did not feel the need to belabor the difference between pseudorandom and random. The context makes it clear that this can't be a random device based on a physically random process.
3) A friend who has a significant math background in crypto stuff has seen the Security Dynamics algorithms (under non-disclosure), and says that they're credible.
That bit of information may mean that a 10^4 sample test is not worth doing.
That vouches for their theory.
That changes our trust from no trust at all into trust in your friend's ability and your assessment of it. :-)
That they insist on programming the cards and keeping the keys themselves, and that they do not allow you to program the cards yourself, is a major problem, no matter how good their math is.
Granted. Their keeping the keys is worth, say, using a linear congruential generator (or worse) in terms of overall security. I was merely curious as to whether they were fools on all fronts, as opposed just to the secrecy front. Eric
participants (4)
-
Brad Huntting
-
Eric Hughes
-
Marc Horowitz
-
Pat_Barron@transarc.com