Secure phones - STU3

[Mike Ingle <MIKEINGLE@delphi.com>]

"lear35!mdbomber@nebula.acs.uci.edu" wrote:
>Subj:   secure phones - STU3

>I browsed through the owner's manual for the AT&T STU-III secure phone
>unit today.  It has no technical information whatsoever (security
>through obscurity?).

Never Say Anything...

>It uses a so called CIK (Crypto Ignition Key), which resembles one of
>those electronic keys that hotels use.  It must be inserted in a
>"lock" in the phone, and turned 90 degrees.  This will enable one of
>the crypto keys that is stored in the phone's battery backed up memory
>(loaded previously by a "COMSEC custodian" through a data port on the
>phone.  The manual warns the phone must be in a relatively secure
>location and points out an emergency erase button that wipes out the
>keys stored in memory.

They should put a mercury switch in it, so if you steal it and move
it around much, it wipes the keys. Also a "duress number" which works
okay, but displays a warning on the other party's phone display, in
case you're forced to call someone with a gun to your head.

>Then you call someone, say you want a secure channel, wait for
>them to insert their CIK (and tell you so), then touch the "secure
>voice" button on the panel.

What all buttons does the phone have? Normal dialing, secure voice,
self-destruct, anything else?

>The manual then says it will go through an "authentication process",
>the results of which will be displayed on the STU-III's screen.  It
>will show data such as the other stations ID number, the security
>level of the channel (secret, top secret, etc), and the baud rate.

What baud rates does it use? How is the sound quality in secure mode?
It must use either a DSP (good sound, high baud) or a vocoder
(robot voice, low baud).

>Does anyone know how this works technically?  My speculation: It seems
>to be a public key system.  The phone's memory seems to contain a
>secret keyring, and a CIK is a 'passphrase' to a secret key, to make
>an analogy to PGP.  Then the authentication process includes
>exchanging a session key for a conventional crypto system - no doubt
>DES.

It could be public-key or DH exchange. Does the manual tell you to
read a hash value to the other party and verify it? If so, it's DH
and that's the protection against the man-in-the-middle. If not, it's
either public-key or DH-like but with authentication. In any case, the
key probably contains a small EPROM which selects and decrypts one of
the keys in the memory.

If classified secret and top secret info is involved, DES would not
be used. The NSA wants us to use DES, but they know better than to
use it for classified info. Probably something similar to Skipjack,
in a similar tamper-proof chip. 

>Apparently the NSA issues the keys to authorized agencies and
>contractors.  The public keys contain information such as the ID
>number of the key, possibly the authorized user's name, the security
>clearance level for that key, etc, which is exchanged during
>authentication.

NSA issues the keys...I feel safer already!
Can you say, "key escrow"?

--- MikeIngle@delphi.com