[4350] in cryptography@c2.net mail archive
Re: add-on crypto hardware
daemon@ATHENA.MIT.EDU (Robert Hettinga)
Thu Mar 18 16:43:27 1999
Date: Thu, 18 Mar 1999 14:25:41 -0500
To: cryptography@c2.net
From: Robert Hettinga <rah@shipwright.com>
--- begin forwarded text
Date: Thu, 18 Mar 1999 11:27:04 -0500
To: "Steven R. Taylor" <staylor@bbn.com>
From: Frank Jaffe <fjaffe@netcom.com>
Subject: Re: add-on crypto hardware
Cc: dcsb@ai.mit.edu, worley@ariadne.com (Dale R. Worley), staylor@bbn.com
Sender: bounce-dcsb@ai.mit.edu
Reply-To: Frank Jaffe <fjaffe@netcom.com>
Steve,
Just a quick note. In the US Treasury pilot, the SafeKeyper is actually
being used to sign the echecks as well. Smartcards are being used by the
payee's (Department of Defenese Vendors) to endorse the echecks for
deposit, and by the Department of Defense to authorize the payments.
The US Treasury has very stringent security requirements, and requires that
dual (or more) controls be in place at every point in the payment cycle.
They meet this requirement in several ways.
First, payments are authorized by the Department of Defense officers
responsible for approving the payments. Two officers each independently
digitally sign a payment instruction file. These officers are using smart
cards for this signature. The signed payment instruction file is then sent
to the US Treasury using a doubly encrypted link (using hardware encryption
provided by IRE).
When received by the Treasury, the signatures are verified, and then the
payment instruction file is converted to echecks. There is a manual
summary total review to confirm that the amounts and number of payments are
as expected and approved. Assuming life is good at this point, then the
Treasury officers each use their security keys to enable the SafeKeyper to
sign and issue the echecks.
Treasury's concerns include not only the security of the operating system,
but also the security of the network, and the potential for information
warfare like attacks. The system, both technology and procedures, has been
designed to address those concerns.
If folks are interested in more details, I can disclose a bit more, but not
to a general public mailing list. Please contact me directly.
At 3/17/99 03:44 PM , Steven R. Taylor wrote:
>At 12:01 PM -0500 3/16/99, Dale R. Worley wrote:
>....snip....
>>
>>This led me to recall seeing an article back in the 1970's in an IBM
>>journal about an add-on crypto hardware module for the IBM 360. Its
>>essential value was that all crypto keys would be held in the module,
>>and data would be passed to the module for processing. (Keys would be
>>delivered to the module encrypted under a master key that the module
>>knew, but not the OS.)
>>
>>I suspect that this is a problem that has been thought about a lot in
>>the intelligence community.
>
>You're right. I don't know of the IBM module to which you refer, but BBN
>worked with various security agencies in the past to create a "signer"
>whose keys never leave the box. It was originally done to support secure
>mail in the defense environment. It was designed for exactly the situation
>you describe - a place where you can't trust the OS nor the path through
>the OS for a PIN. Everything is done in the box. You can see more detail
>at:
>
>http://www.bbn.com/groups/cybertrust/solutions/safekeyper/index.htm
>
>It's currently being used in the echeck pilot at the US Treasury as well as
>other interesting places. The signing of individual checks is done with
>smart card technology, but the signatures for bank credentials and other
>important parts of the system are done inside the SafeKeyper.
>
>You can see more about the system at:
>
>http://www.echeck.org
>
>The keys themselves are generated inside the box - they literally can't get
>out in any usable form. They can be backed up for disaster recovery but it
>is done is such a way as to require the user's physical interaction to
>reload, etc.
>
>The box and it's code, etc get vetted by whatever security organization is
>involved. The most public is FIPS 140-1 Level 3 certification.
>
>Steve
>
>
>
>For help on using this list (especially unsubscribing), send a message to
>"dcsb-request@ai.mit.edu" with one line of text: "help".
-- Frank Jaffe (V) 617-434-1838 (F) 617-434-9889 (E) fjaffe@netcom.com
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@ai.mit.edu" with one line of text: "help".
--- end forwarded text
-----------------
Robert A. Hettinga <mailto: rah@philodox.com>
Philodox Financial Technology Evangelism <http://www.philodox.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
