------------
All this PKCS#15 signaling infrastructure.... and for what purpose? send 24 bytes of authentication data down a serial bus?
The purpose PKCS#15 and its kin is (evidently) to keep the market proprietary, with the standardization of mechanism toolkits (and advanced, attribute-based toolkit mechanism access protocols), that only exist to enable segmentation of markets by vendor and application.
Think about it. This is the Intel strategy: invent lots of layers (to break the 80s IBM monopoly, by market forces), so you can keep making differentiated uP chips, each with one feature different. Then do that faster and faster, rather than compete on slow-moving IP invention. Now, post 1994, do this with security/crypto features.
If we think out loud, we can see that this layering strategy works in the hardware security space, as there is real value to hardware security in the micro and nanocode, etc; supporting the acpi and boot (and spying/countermeasures) coroutines. Apply the doctrine to software security architectures, it just causes market paralysis. Large number of vendors eking out a minor living from a completely fractioned sys integrator market, and small number of chip companies competing for a few large orders at miniscule margins - with few advanced service being delivered (or used!)
If you want to analyze trends in smartcards, you have to analyze what Intel Architecture Labs folks have been working on for the last 10 years, both technology and strategy, when applying the above doctrine to secure controller design and marketing. If I remember right, the UK govt got a classified briefing on all this, about 4 years ago. While focused on the minor issue of covert surveillance for national security purposes (allegedly), the bigger trends re adoption of secure hardware were also presented (allegedly).
Its also fun (in the bar) to plot the convergence of Palladium, TPM, trusted buses, and wireless buses,and secure controller microrecoding and key loading, OTAR. Add in a dose of paranoia with the inhibition-breaking alcohol, and we might break the European malaise re infrastructure-grade smartcard architectures, yet!
Invent more software standards! Set up more conformance labs! Bring on the formal methods! After all, these are (sic) the things that define the dynamics of commodity (security) infrastructure markets!
Did I mention Taiwan is now mass making $4 CCID-enabled USB dongles with a custom uController, sold in the US at $7 retail? Bang. The minimum manufacturing price point of $15 readers maintained by European (and VISA) marketers for 20 years is gone! Trouble is, there is no margin for advanced services, either, like flexible, attribute-based signaling - or VISA services value add. But then, the technology probably didn't bring anything that a 24 byte CCID message payload didn't accomplish just as well, and not everything do with network security requires a payment service provider!
----- Original Message ----- From: "Vladimir Beker" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Wednesday, February 09, 2005 8:27 AM
Subject: RE: [Muscle] Some questions about PKCS#15
[Vladimir Beker] Agree with you. There are 2 issues here. One is derivation mechanism, another one is that many attributes of pin apply here.
>> >>>However from the user point of view, >>>it is password, so min/max length and other password attributes still >> >>take place. >> >>of course you can misuse a pin a object for this, but I don't think >>there's an elegant solution for this (using pkcs15, not to mention >>pkcs11 ;-) > > [Vladimir Beker] Regarding to PKCS#15 - it is not elegant (it would be > better to have missing attributes in auth. key object instead, just to > make them OPTIONAL. So, presence of these attributes (such as min. length) > would mean that it is actually password derived.
of course you would need to specify the alg and parameters to derive the key as well ...
Probably the solution would be:
To define new kind of object: derived_auth_key, which is the same as auth_key + derivation mechanism + the same id as auth. pin to be derived.
So actually we have 2 records but define 1 real object. It is a bit dirty trick, but it allows not mixing attributes of key and pin
[Vladimir Beker] Strictly speaking you are right. But I would consider such thing as the least evil.
that's not allowed. to quote pkcs15:
CommonObjectAttributes ::= SEQUENCE { ... authId Identifier OPTIONAL, ..., ... } (CONSTRAINED BY { -- authId should be present in the IC card case if flags.private is set. -- It must equal an authID in one AuthRecord in the AODF -- })
but I don't that many libraries stumble over this.[Vladimir Beker] Agree.
> Or it may be > something that the card will not accept in VERIFY command (such as 0xFF).
id != reference
**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content ** **************************************************************************************************
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
