Re: Intel Symantec v. ZKS?
In [EMAIL PROTECTED], on 04/29/99 at 03:40 PM, Anonymous [EMAIL PROTECTED] said: William H. Geiger III writes: One has to wonder if this is the actions of a company that is trustworthy enough to supply RNG's to the community. IMHO it is not and I sincerely hope support for the PIII is *not* included in /dev/random and/or IPSEC. I will not be adding any support code in my software. He quotes John Markoff's story in the New York Times: Earlier this month, an Intel executive called executives at the Symantec Corporation, maker of the popular Norton Antivirus software, and told them that the demonstration program was "hostile code." Symantec agreed that the program fit its definition of a type of malicious program known as a Trojan horse, so it included the software in its continually updated list of dangerous programs, which include viruses, that cause warnings to pop up on its customers' computers. In fact, this is perfectly reasonable on the part of Symantec, and if I had a PIII I would absolutely want my virus detection software to catch code which enables the serial number. Any such action on the part of downloaded code is malicious and not in my interests, and anything the software can do to prevent it is good. This sets a precedent that code which reads the serial number contrary to the user's wishes is hostile. This should help dissuade over-eager software registration programs from using the serial number in their registration process. No antivirus software can detect all programs which try to read the serial number, but by making clear that such actions are antisocial it will help restrict its use. Granted, it would be better if the serial number didn't exist at all (but of course we know that network interface cards have always had serial numbers, don't we?). And it would be better if Intel's method of turning off the serial number worked right. But given that it does exist in a family of processors which will probably be widely used (ineffectual boycotts to the contrary), users do benefit by having unauthorized serial number programs be detected and identified as dangerous. No, all this does is set the precedent of a major corporation flexing it's muscle in an attempt to silence those who would expose their lies. This is a typical case of corporate CYA and I am appalled by it. Do you honestly think that Symantec is going to list any Microsoft products as a virus when they covertly turn on this feature? As far as ineffectual boycotts, I am not asking for the software not to run on a P-III, I am asking that specific support for the P-III RNG not be added. I don't think requiring Intel to shape up if they want to be players in the crypto community is a Badthing(TM). [Personally, given how bad the random number sources are in most software, I'd say you are not doing your users a service. --Perry] Of course Perry is absolutely right. The Intel RNG can provide a badly needed source of randomness. The real problems are first, as was pointed out here yesterday, Intel has not documented how to read the RNG (and is apparently only supplying that information to partners like RSA and Microsoft). And second, how should we count the entropy added by the RNG. Here is where the trust issue comes into play. If it is really a good RNG we can count every bit as a bit of entropy. If we don't trust it, we can use the RNG data but not count entropy from it at all. Or we could split the difference and "semi" trust Intel, counting only some fraction of the nominal entropy provided by the RNG source. So we should just blindly use a RNG of unknown properties from an untrustworthy company? What will happen next when the P-IV has built in crypto module (it is the next logical step)? Yes many programs have bad random sources, many programs have bad crypto period. I don't use them and I don't support them, plain and simple. I have to reiterate my original statement from the /dev/random thread that I started: "I have specific concerns, the #1 of which is that no analysis of this program has been done!! If this was a crypto algorithm and one was to use it without any analysis of it but only because "it came with the OS" one would be severely chastised by the community. Unfortunately I am seeing too many programmers blindly using /dev/(u)random on this very basis. I am not saying it is a bad program, I am not saying it is a good program, I am saying it is an unknown, and with something as important as one's random number pool IMNSHO an unknown is not acceptable." Here we have a RNG on unknown properties and yet there is already those who wish to blindly rush out and uses it. You really should know better. -- --- William H. Geiger III http://www.openpgp.net Geiger ConsultingCooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP MR/2 the only way for secure e-mail. OS/2 PGP 5.0 at:
Re: forwarded message from Steven M. Bellovin
Hi, I'm Brad. We did the "Atom-Age RNG" box. Jim Thompson forwarded your mail regarding his comment about us: Here in my hands, I have an "Atom-Age" HW RNG device. Sounds interesting -- do you have a URL or other contact info? Regarding self-test, no, it's really a simple box. I just wanted to get the numbers right. No whitening, just straight bits. I'm a big fan of raw numbers. I'm completely wigged-out about the concept of performing whitening before a user sees numbers. I understand the desire for self-validation in the box, I just wasn't headed there myself. I've always believed that this sort of thing is best done explicitly by the user. Doing the tests one's self - Doctor's advice even with a "fancy" RNG - this is NOT MEANT as a catty remark, but I REALLY THINK this is important. (you didn't trust us, did you? :-) Rhetorically, what's the point of testing your RNG at power-up? Either the circuit is good or it's bad. Who's to say that a circuit that can't be trusted to start-up and spit-out good random numbers won't start spitting-out bad numbers during normal operation? I'd much prefer to have the host checking the numbers as a matter of normal operation. I'm not too thrilled about expecting the RNG to check itself, in any situation. About the only thing that hoses up the numbers in my box is low batteries. For that reason, I put hardware in the box to constantly monitor the three separate isolated power supplies. The uP shuts things down if any of the power supplies go too low. Personally, I've gotten so used to the way it works (I've been using it for more than three years) that I just don't worry about the numbers on my own box much any more. I've run this thing through muck and mire, finding that if the micro hasn't shut things down because of a power supply problem, the numbers are going to be good. If someone can put together a streaming test for up on the host computer (*nix and/or 9X/NT) and would be kind enough to provide source code, I'd be highly gratified, and thankful. I would of course gladly send it along with the boxes as a way of helping out those who don't want to worry about or think too much about this issue. All our uP does is collect the bits and run an RS-232 port. Plus a little bit of housekeeping. You get the uP source code it's documented (imagine that). Worried? Careful? Buy the $99.00 microprocessor development kit from Motorola, scan in the text, audit it, reassemble it burn a new uP. We chose the uP and even socketed the uP for that exact reason (the kit includes an assembler, a programmer and a blank uP!). The board comes with schematics. There's even a breadboarding area for experimentation. Want to play with high-dollar noise diodes? Change the amplifiers? It couldn't be easier, get out a soldering iron. A few other nice features. Big steel box. Thick steel. Dangerous in flight. This is a labor of love and you're welcomed to join in. I do keep a few dozen or so in stock and they're easy to build: custom steel CNC box fabrication, volume manufacturing on line, etc. If I needed to, I could and gladly would make them in the thousands. Thank goodness, though, it's been fun to do. Especially since the odds of making back even the development costs are 10e6-to-1. Essentially, I wanted to answer the question: "If it's so easy to do this with just a diode, why doesn't anybody make a cheap box that does that?" Unfortunately, it took me about two solid months of engineering work to provide the answer, being that it takes a lot of focused effort to get a reproduceable circuit with numbers that are really good and to get that circuit into a form ready for volume production. Add to that the distinct possibility that I'll only sell a few! What the heck, it's only a $200 box. Big deal. But, I've found that it's really a fine little box for what it is. I do sincerely appreciate your interest. Best regards, Brad Martin NSCD LLP P.S. Atom-Age is a small company we run on the side. You can get more information on who we are by going to our REAL company's web site, at: www.nshore.com. P.S.S. Of course, I'm sure that a lot of the people using the Intel stuff will check their numbers, too - no matter how good they say they are - but that's the kind of guys we are :-). If they're good numbers, I think that (in general term) the work by Intel is a very good thing to have happened. - b. P.S.S.S. I hope the Intel RNG isn't a pseudo RNG hash of the PID ;-) - b. begin:vcard n:Martin P.E.;Brad x-mozilla-html:FALSE org:North Shore Circuit Design L.L.P. version:2.1 email;internet:[EMAIL PROTECTED] title:Managing Partner tel;fax:(512) 448-1415 tel;work:(512) 448-1114 x111 adr;quoted-printable:;;3910 South IH-35=0D=0ASuite 255;Austin;TX;78704;USA x-mozilla-cpt:;0 fn:Brad Martin P.E. end:vcard
Testing RNG devices
Brad Martin: Doing the tests one's self - Doctor's advice even with a "fancy" RNG - this is NOT MEANT as a catty remark, but I REALLY THINK this is important. (you didn't trust us, did you? :-) Statistical tests don't solve this problem. It's easy to design an alleged RNG which passes all common or even all publically known and efficient statistical tests, but contains regularities known only to those who have observed and understood the device design and circuitry. Such regularities would make cryptanalysis of PRNGs and ciphers depending on this RNG easy. Statistical tests can detect, with high probability, when an RNG device of trustworthy design deviates, due to some natural damage, from its specifications. The best way to establish trust in an RNG device may be to (1) publish the design specification. (2) design and distribute both software and hardware which verifies whether a particular device is operating according to that specification. This involves testing the physical characteristics and circuit design of the device, _not_ the statistical characteristics of the data it generates. [EMAIL PROTECTED] http://www.best.com/~szabo/ PGP D4B9 8A17 9B90 BDFF 9699 500F 1068 E27F 6E49 C4A2
NY Times article on Shamir's public key breaking machine
http://www.nytimes.com/library/tech/99/05/biztech/articles/02encr.html> gives a very superficial overview of a paper to be presented Tuesday that describes a hardware attack on public key cryptography. "Researchers said that if his machine worked it would mean that cryptographic systems with keys of 512 bits or less -- that is, keys less than about 150 digits long -- would be vulnerable in the future, an exposure that would have seemed unthinkable only five years ago. The longer 1,024-bit keys that are available today would not be vulnerable at present." Martin Minow [EMAIL PROTECTED]
Triple-DES in the Schlumberger java card
A javacard created by Schlumberger (the "Cyberflex
Access Card") both implements cryptographic functions
(RSA, triple-DES) and allows you to download your
own programs to the card. Moreover, you can reuse
the EEPROM space by deleting a program and
downloading a different one into the same space.
Here I will comment on Schlumberger's implementation
of the javacard specification with respect to triple-DES
(3DES). Schlumberger has a sample java program showing
how to do 3DES on the card posted at their Austin web site
for anyone to download (http://www.cyberflex.slb.com).
(This program will not run without the encryption engine
on the Access Card. Schlumberger will only send
encryption-enabled smart cards to U.S. addresses.)
There are some problems with the 3DES implementation.
I will begin by explaining some of the differences
between ordinary java and javacard java, as this will
also highlight some features that are specific to
Schlumberger's implementation of the javacard
specification.
Programs for the javacard are simply written in java.
But because of the resource constraints on a smart card
(memory and processing power), some of the features
of java cannot be used, however. These include
32 and 64-bit integers, floats and doubles, unicode
characters, threads. There is no dynamic class loading
and no garbage collection.
Since there is no dynamic class loading, the java virtual
machine can be (and is) split up into two parts. The
first of these is used as a preprocessor to further process
the java byte code before downloading onto the card.
Schlumberger's preprocessor is call "mksolo32.exe".
So suppose you write a java program des3.java. You
then compile this with the java compiler in the ordinary
fashion to des3.class. Next, you compile des3.class with
mksolo32.exe to create a file called des3.bin.
Note that in the javacard documentation the extention of
compiled class programs is ".cap" (for compiled applet)
not ".bin". But Schlumberger calls its compiled class
programs "cardlets" instead of "applets", and the
change in name seems justified, because in the
Access Card you can write java programs that use the
main() method, as well as those that extend the
Applet class.
After compiling des3.class to des3.bin, you are ready
to download des3.bin onto the card. Schlumberger
provides a software development kit for downloading
and managing cardlets. The kit also comes with a
cardreader-the Lintronic 210, which does not need
a separate power supply, because it draws power
from the keyboard port. (The kit also contains an
APDU manager, for sending byte instructions to
the card, and receiving and displaying byte output.
Alternatively, you can use your own card terminal
implementation.)
To download the des3.bin cardlet, you only need to
assign it a filename and sign it with a verification
key corresponding to the cardlet verification key
which is already stored on the Access Card.
The Access Card will authenticate the cardlet before
allowing it to be download into EEPROM. (This is
in addition to the requirement to authenticate yourself
to the card through one of the card's authentication
keys, which shows you have permission to perform
this type of activity.)
Once the program (des3.bin) has been downloaded
on the smart card, you create an "instance" of the
program, which includes an allotment of memory
space for the data container needed by the program.
You can create multiple instances of the same
program
The program is accessed by sending it bytes (APDUs)
in five-byte instruction sets, along with any data.
These are usually labeled {CLA, INS, P1, P2, P3,
data}. P3 is the length of the data. CLA is the
"class" byte, while INS is the "instruction" byte.
P1 and P2 are there to be used as switches (much
like CLA and INS, except that CLA and INS must be
specifically declared).
The 3DES program listed at Schlumberger's site is
called CryptoTest.java. The following group of
APDUs does a triple-DES ECB encryption on the hex
string "0102030405060708": {03,50,00,00,08,
0102030405060708}. The output from the card should
be "01B45F3A1C9C703E". Cross-checking with other
3DES programs shows this is the correct sequence
of encrypted bytes.
However, the CryptoTest program simply locks on
the card that came with my development kit.
Inspection of the code shows that the following
line under the RunTest5() class must the changed
from
des3key.setKey(key3, (short)0);
to
des3key.setKey(key3, (short)0, (short)0, (short)16);
This part of the program then runs fine. Similar
changes must be made in RunTest1 (a DES encryption),
RunTest2 (another DES ECB encryption-decryption),
RunTest6 (a MAC with 3DES), RunTest7 (a MAC with
DES), and RunTest8 (3DES on a 24-byte message to
illustrate cipher-block chaining).
With this change, Tests 1-5 will run correctly.
However, Tests 6-8 still will not work. These
three latter tests use cipher-block chaining, so
as you might expect, there is a problem with
the
