[4366] in cryptography@c2.net mail archive
Xerox supplies stego?
daemon@ATHENA.MIT.EDU (Brown, R Ken)
Mon Mar 22 10:22:26 1999
From: "Brown, R Ken" <brownrk1@texaco.com>
To: cryptography@c2.net
Date: Mon, 22 Mar 1999 08:34:45 -0600
Probably not news to most of you, but I didn't realise they did this sort of
thing.
http://www.xerox.com/xsis/dataglph.htm
[...]
"DataGlyph technology allows ordinary business documents to carry thousands
of characters of information hidden in these unobtrusive gray patterns that
can appear as backgrounds, shading patterns or conventional graphic design
elements. Often, their presence will go completely unnoticed. "
[...]
"As a final step, the bytes of data are randomly dispersed across the glyph
area, so that if any part of the glyph area on the paper is severely
damaged, the damage to any individual block of data will be slight, and
thus easy for the error correcting code to recover. Together, error
correction and randomization provide very high levels of reliability, even
when the glyph area is impaired by ink marks, staples and other kinds
ofimage damage."
Ken
> -----Original Message-----
> From: Robert Hettinga [mailto:rah@shipwright.com]
> Sent: 17 March 1999 22:16
> To: cryptography@c2.net
> Subject: Re: add-on crypto hardware
>
>
>
> --- begin forwarded text
>
>
> Date: Wed, 17 Mar 1999 15:44:33 -0500
> To: dcsb@ai.mit.edu
> From: "Steven R. Taylor" <staylor@bbn.com>
> Subject: Re: add-on crypto hardware
> Cc: worley@ariadne.com (Dale R. Worley), staylor@bbn.com
> Sender: bounce-dcsb@ai.mit.edu
> Reply-To: "Steven R. Taylor" <staylor@bbn.com>
>
> 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".
--- 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'
