I've been stalking Mykotronx with phone and smail since right after the announcement, and finally got through the guy who kept telling me that I'd undertand if I just knew a little more crypto, to the guy who really know what was going on and wanted to tell me. This is what I found out: Mykotronx MYK-78 has been identified as the Privacy "Clipper" chip. The "Clipper" name comes from Washington, and the guys at Mykotronx know about the Intergraph chip. The data sheets, as those of you who have read them know, are confusing, incomplete and internally inconsistent. This is evident even if you do not consider that they are to implement the social protocol described by Dorothy Denning (her 19-Apr-93 paper, as published in Cypherpunks). After some discussions with Mykotronx, I was able to convince them of the truth of the last paragraph and to have them explain just what the chip was designed to do. I would also like to emphasize that these discussions revealed that the poor quality of the documentation does not result from any attempt to obscure the operation of the chip, they were very forth coming and eager to discuss its operation. The deficiencies result more from the nature of a military contractor's relationship to its one customer: the customer understands how to use the chip so there's no pressure to get it described carefully. Going public was a bit of a surprise to them, in fact the announcement was made during their application engineer's vacation. I am sure there is an interesting story in this timing, but the people I was talking to didn't seem to know it. On to the chip: You don't just hook up a clear-text bit stream to one end and get a Denning-stream out the other. It needs a bit of care and feeding. At startup it requires a Random Seed (8 bytes/64-bits) and a crypto-variable CV (10 bytes/80-bits) for its DES-type algorithm. This is Denning's "skipjack" algorithm and, like DES, is a symmetric key block cypher, which performs in all the DES modes: 64-Bit Electronic Code Book (ECB) 64-Bit Cypher Block Chaining (CBC) 8/16/32/64 Bit Cypher Feedback 64-Bit Output Feedback (OFB) In the last three modes the encryption of each block is dependent on the previous blocks. (If you care to know more about DES modes, see FIPS-PUB 81 which is cited in the data sheets.) One other thing about Skipjack: Denning describes it as having "32 rounds of scrambling" and this is supported by the data sheet's timing charts, which note 64 clocks cycles to complete an encryption. Since this would operate on an 8-byte/64-bit block, with the 15MHz internal clock we appear to have roughly a 10M-bit/1.3MB transfer rate in encryption/decryption. This is fast enough for the average telephone, or several telephones, or maybe a stereo CD. It's probably just average performance for 1 micron technology and some units clock up to 30MHz (they expect 0.8 micron eventually, with improved performance). Back to the Crypto-Variable, CV. The CV is the session key, is selected off-chip, and must always be accompanied by a 3 byte/24-bit checkword. Where do you get the check word?... you ask the chip! If you load a CV with a bad checkword, the chip sets its ERROR line -- oh, sadness. But then you can read out a good checkword, and subsiquently reload the same CV with the good checkword (happy now?). The checkword is actually just the first three bytes from an application of Skipjack to the CV. Do all this and the chip is loaded and ready for plaintext. You could just give it an Encryption command, and start pulling cyphertext out the other side, but who would understand it? First you have to get the key information out of the chip and send it to the chip on the other side of the link. Skipjack is DES-like so to run a decryption mode on the other chip we're going to have to send it the session key, CV, and the Initial Vector, IV, which is the starting state of the stream for the non-ECB modes of operation. We selected CV ourselves, and learned its checkword during the startup experience, but where's IV? Well, we generate it using "a feature not found in current DES chips" (data sheet, 1-3). And quite a feature it is, too. We use this command, Generate IV, and it makes all 8 bytes/64-bits of the IV, based on the Random Seed... But That's Not ALL! You issue the Generate IV command three (3) times to get the full 24 byte/192-bit LEEF block. LEEF = Law Enforcement Exploitation Field. (I wrote this down very carefully to be sure I had it right.) ...Actually, you issue a Read Data command after each Generate IV command, but I won't bore you with details. The first 8 bytes/64-bits are called L1 or LEEF-1, the second 8 bytes/64-bits are L2 or LEEF-2, and then here is the IV we've all been waiting for, in its full 8 byte/64-bit glory. You probably noticed that LEEF is 24 bytes/192-bits long, and has the structure [L1,L2,IV]. Mykotronx is not supposed to tell us the structure of L1,L2. The interesting thing is that [CV,checkword,L1,L2,IV] is a self-checking unit. The receiving chip checks it as it is loaded. If something is wrong, the chip sets its ERROR line. If CV is fermished, you have to get all the way to IV before you're rasberried. In transmitting this we are advised to encrypt CV because it is, after all, the session key. OK, so we are encrypting and the other chip is decrypting. Suppose something happens and the other chip wants to talk to us, so that it encrypts and we decrypt. It has all it needs to encrypt and we have all we need to decrypt, but one more thing has to be done. We need to save the state of the chaining cypher so we can resume it at the same place in the chain when we return to encrypting. Use the Save State command, which pops out 8 bytes/64-bits of Saved State, SS, or the current contents of the Skipjack encryption register. To make this a bit clearer, if we pulled the Saved State right after Generate IV, we'd find SS = IV. The chip's serial number is 4-bytes/32-bits long, not the 3.75 bytes/30-bits Denning reported, but don't worry, _you'll_ never see it. It and the family key are written in over pins Vpp1 and Vpp2, which are then burned out. All chips are currently planned to have the same family key, but if you happen to meet a chip with a different family key and it sends you [CV,checkword,L1,L2,IV], you could understand it. That's the main part of what's missing from the data sheets. The rest works pretty much as described, and is at a level of detail too fine to interest anyone except a compulsive hardware wonk. Oh, one more thing, on page 1-4 where the Configuration Register is shown with two "Arm CV" bits, the one at position D5 should be "Arm IV". -a2. ps: I will be at a meeting the rest of the week, so please don't expect me to respond to requests for clarification until I return. Sorry. -a2.
Arthur sez:
I've been stalking Mykotronx with phone and smail
And I've been peering over his shoulder for much of that time. I'd like to comment on some of the unapproved ways to use this chip. The way that the chip enforces the wiretap protocol is by not working as a pair unless the LEEF's are transferred from one chip to another. Since these LEEF's are presumed to go out in the clear, tapping is reasonably assured.
LEEF = Law Enforcement Exploitation Field.
I really am astounded at the names these people use. It does give rise to a great new slogan, though: "Stop Government Exploitation Fields!" Now suppose that there was a law requiring use of this chip. One could still create an untappable system just by not sending the LEEF's in the clear. So, for example, you do a D-H key exchange with a 600 bit modulus. Then the originating chip transmits the CV, LEEF's, etc. (as I count 282 bits), XORing with the D-H key, i.e. using a one-time pad. Now the LEEF's have been transferred, but not revealed to any eavesdropper. With a 600 bit modulus in the key exchange you could transmit one set of keying material each way. There's a great hack here to be had. These AT&T secure phones with the wiretap chip inside have internal modems and run some coordination protocol to synchronize. Almost certainly such an initial protocol must have retry paths in its state machine; otherwise the reliability would suffer. So we could make a compatible phone that initially tried to determine if another such phone was on the other end; if so, proceed with the blinded LEEF transmission. If not, drop back and try the wiretap protocol. In fact, those of you who have seen Shimomura's and Lottor's work with hacked cellular phones know that it might be possible to put this hacked protocol right in the AT&T phone itself! If the phone has a ROM of some type which contains the microcontroller code, it could be reverse engineered and reprogrammed. If I were mandated to use the chip in a commercial product, I'd put three buttons on the phone: CLEAR (icon=open doors) SECURE (icon=closed doors) TELL THE GOVERNMENT (icon=benevolent face) Pressing the third button would use the AT&T protocol, pressing the second would encrypt the LEEF's. "AT&T: Helping the government to reach in and touch you." There might be another technique. There is a Write CV command that is accepted in normal operation. (Some CV must be put in during initialization after reset to reach the idle state, i.e. the normal operating state.) This command requires the check word, but that's easily generated in the normal manner. It is possible that changing the CV requires generating another set of LEEF's; that's not clear to me, but Arthur thinks you can. If, however, one can just change the CV at will, one could send the LEEF's in the clear and then immediately change the CV (session key). Now the LEEF has been sent but the conversation makes no sense. My money is that this is interlocked with IV generation, though. Eric
participants (2)
-
Arthur Abraham
-
Eric Hughes