Concerning the much easier topic of designing security boundaries for smartcard CPUs, our more immediate problem in muscle, the doctrine went like this. If you use machine-only readable coding (like DER), and the coding is based on strong type theory, you know from the abstract syntax what you are signing. Put another way, if the device cannot decode the stream according to the X.509 ASN1. types, it should not sign it. This used to be one of the distinguishing criteria defining high vs medium assurance CAs.
This is why I said in the original spec: dont even bother decoding it (the DER-encoded cert)....so as to save some time. One ought to do such decoding, but in a v1 code base one need not - a concession to doctrine so cleartext keys get addressed. That latter goal was more critical AND more urgent than any engineering doctrine.
When we started VeriSign, for example, we used 442-daisy-chained BBN Safekeypers as CAs - whose high assurance had nothing to do with high tech (it was a clumsy old 68010 powerhog, sending EMF in all directions, in the commercial version) or "secret" techniques: it was its controlled interfaces dedicated to it being an embedded CA, and its design doctrine concerning the "handling" of data in a data-centered redundant control system - of which the certificates were a critical part. Its fascinating to read and follow NSA/DoD doctrine and dogma, expressed in the very language of specification and design, underpinning a specific doctrine of security engineering. Its a shame, but most of this method technology is now lost, dispersed at the end of the cold war, when such careful thinking (and counter-thinking) became redundant.
From: Christian Schneider <[EMAIL PROTECTED]> Reply-To: MUSCLE <[EMAIL PROTECTED]> To: MUSCLE <[EMAIL PROTECTED]> Subject: Re: [Muscle] XCard documentation? Date: Thu, 06 May 2004 23:05:18 +0200
Either way, its a day or less work for your average Indian PhD programmer. The last way would not require any modifications of the javacard applet, I suppose. Im just trained in secure device theory, so its hard for me to volunteer to make a crytodevice into a generic hash signer, without knowing whats its signing! I used to using signing for control purposes.
The problem is that the cryptodevice does not know what it signs in both methods. It does not matter if it signs the hash or the real data. Important is that the user knows what he signs. This depends on the document viewer being used. Ideally the document viewer would be included in the crypto device. So the user could be really sure what he is about to sign. A german university is currently developing such a device where the cryptodevice can control the monitor and keyboard. So the user can be sure no trojan lets him sign the wrong document.
As long as a cryptodevice has no included trusted viewer it is equally secure in my opinion if you sign a hash or real data.
best regards,
Christian
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
