Hello,
food for thought:
Take a look at the Global Platform PUT_KEY command. It follows pretty much your idea of a small header with subsequent key data. However it does have more key management information that goes along. If you use the Secure Channel protocol, there are two ways to encrypt key data: either encrypt the complete command data (or response data in case of key export) or only encrypt the key data part using what GP refers to as "sensitive data encryption". The sensitive data encryption uses a separate key for the encypher/decypher mechanism.
The mechanisms and API defined by GP are useful if you want to import/export keys but do not want to have the key encrpytion keys be part of the application itself. The keys for the Secure Channel protocol are own and stored by the corresponding (Issuer) Security Domain and the corresponding cryptographic services are available via the Secure Channel API.
Let me know if you want further details.
Greetings (from a GP fan...)
Klaus
| Karsten Ohme <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 24.11.2005 17:09
|
|
Hello,
How should or could the encrypted key blob format look like?
At the moment the header is starting with one byte declaring the key
encoding, only unencrypted, plain, is supported right now, then the key
type and the key size. After this header the key data starts.
A simple approach would be to set the byte declaring the key blob
encoding to encrypted and encrypt the key data. But with this approach
the used key and algorithm must be saved somewhere else, so that it is
possible to decrypt it.
To eliminate this two bytes specifying the algorithm and key could be
introduced which are saved prefixing the key data.
Any suggestions?
Also interesting would be the usefulness of this feature. What can be
done with it?
Keys could be exported with a key which was generated on card and never
leaves the card. So it would be possible to swap out keys in a secure
way and import them later again.
One problem is migration. I might be nice to migrate all keys to another
token, but this can produce security risks, e.g. a card generated key
should always stay there and never leave the card, the migration would
allow this.
Also all key flags, cipher policies and so on are lost, if a key is
exported and later imported, e.g. an exported key can never again has
the flag "generated on card", because this is not sure.
Karsten
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
