[2499] in cryptography@c2.net mail archive
RE: NYT Article on Groat Spy Case
daemon@ATHENA.MIT.EDU (Trei, Peter)
Tue Apr 14 10:21:41 1998
From: "Trei, Peter" <ptrei@securitydynamics.com>
To: "'Phil Karn'" <karn@qualcomm.com>, reinhold@world.std.com
Cc: cryptography@c2.net
Date: Tue, 14 Apr 1998 09:47:43 -0400
Phil Karn writes:
> >community's real concerns about widespread cryptography may be.
> Software
> >cryptosystems, like PGP running on a PC, are extremely vulnerable to
> >bag-job attacks, but next generation systems using smart cards may be
> far
> >less vulnerable.
>
> Indeed. I have long felt that the most direct and logical way to
> target any software cryptosystem, no matter how strong its
> cryptography, is to pull a bag job and install a trojan horse. For a
> system like PGP that has no perfect forward secrecy to
> compartmentalize the damage from a key compromise, this is especially
> easy. Just modify the PGP binary to quietly squirrel a copy of the
> user's secret key into his next message and pick it up later with a
> tap on his line. The trojan should then patch itself out to make it
> less likely to be discovered later.
>
[...]
> Phil
>
[Please excuse my lack of standard quoting. I'm using
Microsoft's braindead version of mail - MS Exchange]
One semi-defense against trojan attacks on crypto systems
can be seen in CDSA - Intel's Common Data Security Architecture.
This allows different security related services to be
dynamically slotted into the operating system, including modules for
crypto
services, cert management, trust policy management, data
storage,
etc, etc. These all interact with applications through the
CSSM - the Common Security Services Manager.
The trick is that all the modules are signed, and the CSSM
checks
the integrity of each module loaded, and the modules check the
integrity of the CSSM. The system won't work unless all the
signatures check out and the root signing authorities for the
module certificates are acceptable to the CSSM. The capabilities
manifest of each module is also checked - an 'espionage enabled'
exportable CSSM won't link a strong crypto provider, for
example.
To defeat this, you'd have to patch and subvert all the
signature checks in the system simultaneously. This is
possible, but non trivial, since you may not know ahead of
time just which modules are being attached (and some may be
inaccessible - for example, on a smartcard).
Of course, this also makes it a lot tougher to 'fortify' a
weak application.
Peter Trei
ptrei@securitydynamics.com
