Crypto driver -DCP

Marek,

I have a question about the proper way to implement a feature. The DCP has the ability to read a key for encryption/decryption from on chip fuses. The current driver doesn't support this and as far as I can tell, there's no clean way to do that within the Linux crypto API.

Do you have any suggestions on how to handle that?

My best idea so far is to modify the driver so that if setkey is passed a key with a length of 1 byte, the driver uses the on chip key. I'm not sure if that would make it into the official kernel.

Quoted 8 lines · Jay Monkman

Marek,

I have a question about the proper way to implement a feature. The DCP has the ability to read a key for encryption/decryption from on chip fuses. The current driver doesn't support this and as far as I can tell, there's no clean way to do that within the Linux crypto API.

Quoted 5 lines

Do you have any suggestions on how to handle that?

My best idea so far is to modify the driver so that if setkey is passed a key with a length of 1 byte, the driver uses the on chip key. I'm not sure if that would make it into the official kernel.

What is this key and who is supposed to have access to it?

Quoted 11 lines · Herbert Xu

Quoted 10 lines · Jay Monkman

Marek,

I have a question about the proper way to implement a feature. The DCP has the ability to read a key for encryption/decryption from on chip fuses. The current driver doesn't support this and as far as I can tell, there's no clean way to do that within the Linux crypto API.

Do you have any suggestions on how to handle that?

Quoted 5 lines

Quoted 3 lines

My best idea so far is to modify the driver so that if setkey is passed a key with a length of 1 byte, the driver uses the on chip key. I'm not sure if that would make it into the official kernel.

What is this key and who is supposed to have access to it?

It's an AES128 key stored in the CPU's OTP registers, so noone ought to be able to read it out.

Quoted 16 lines · Marek Vasut

Quoted 15 lines · Herbert Xu

Quoted 13 lines · Jay Monkman

Marek,

I have a question about the proper way to implement a feature. The DCP has the ability to read a key for encryption/decryption from on chip fuses. The current driver doesn't support this and as far as I can tell, there's no clean way to do that within the Linux crypto API.

Do you have any suggestions on how to handle that?

My best idea so far is to modify the driver so that if setkey is passed a key with a length of 1 byte, the driver uses the on chip key. I'm not sure if that would make it into the official kernel.

Quoted 4 lines

Quoted 1 line

What is this key and who is supposed to have access to it?

It's an AES128 key stored in the CPU's OTP registers, so noone ought to be able to read it out.

No I mean who is supposed to have access to it? Everyone?

My understanding (!) is that everyone should be able to use this key to encrypt/decrypt their data using the AES128 engine in the DCP.

Quoted 2 lines · Marek Vasut

My understanding (!) is that everyone should be able to use this key to encrypt/decrypt their data using the AES128 engine in the DCP.

If that's the case just make it the key you use if setkey has never been called.

Quoted 6 lines · Herbert Xu

Quoted 2 lines · Marek Vasut

My understanding (!) is that everyone should be able to use this key to encrypt/decrypt their data using the AES128 engine in the DCP.

If that's the case just make it the key you use if setkey has never been called.

Shouldn't you always call setkey when using symetric crypto ?

Quoted 5 lines · Marek Vasut

Quoted 4 lines · Herbert Xu

Quoted 2 lines · Marek Vasut

My understanding (!) is that everyone should be able to use this key to encrypt/decrypt their data using the AES128 engine in the DCP.

Quoted 4 lines

Quoted 2 lines

If that's the case just make it the key you use if setkey has never been called.

Shouldn't you always call setkey when using symetric crypto ?

Normally yes but we don't require it so in this case it should be fine.

This does look somewhat hacky to me. Wouldn't it make more sense to add a CRYPTO_TFM_REQ flag ?

Quoted 2 lines · Marek Vasut

This does look somewhat hacky to me. Wouldn't it make more sense to add a CRYPTO_TFM_REQ flag ?

What are you going to do when you have more than one hard-coded key? A flag is a non-starter.

Quoted 6 lines · Herbert Xu

Quoted 2 lines · Marek Vasut

This does look somewhat hacky to me. Wouldn't it make more sense to add a CRYPTO_TFM_REQ flag ?

What are you going to do when you have more than one hard-coded key? A flag is a non-starter.

Well, abusing a non-well-defined part of the API is also not a nice way to do it. Maybe we should consider some other -- third -- option ?

Quoted 5 lines · Marek Vasut

Quoted 4 lines · Herbert Xu

Quoted 2 lines · Marek Vasut

This does look somewhat hacky to me. Wouldn't it make more sense to add a CRYPTO_TFM_REQ flag ?

Quoted 5 lines

Quoted 2 lines

What are you going to do when you have more than one hard-coded key? A flag is a non-starter.

Well, abusing a non-well-defined part of the API is also not a nice way to do it. Maybe we should consider some other -- third -- option ?

I'm waiting to hear it :)

Quoted 4 lines · Marek Vasut

Quoted 3 lines · Herbert Xu

Quoted 2 lines · Marek Vasut

My understanding (!) is that everyone should be able to use this key to encrypt/decrypt their data using the AES128 engine in the DCP.

Quoted 3 lines

Quoted 2 lines

If that's the case just make it the key you use if setkey has never been called.

Shouldn't you always call setkey when using symetric crypto ?

Normally yes but we don't require it so in this case it should be fine.

Cheers,

I have another question. The DCP (and other crypto accelerators on other SOCs) supports key slots - basically write only RAM that's used to store keys so they can be used for encrypt/decrypt operations. DCP supports 4 key slots, other devices have different numbers. Do you have any suggestion for how to add support for something like that to the driver?

Quoted 7 lines · Jay Monkman

I have another question. The DCP (and other crypto accelerators on other SOCs) supports key slots - basically write only RAM that's used to store keys so they can be used for encrypt/decrypt operations. DCP supports 4 key slots, other devices have different numbers. Do you have any suggestion for how to add support for something like that to the driver?

So these would allow faster switching of keys I presume?

That would be one use, but a more likely use would be to prevent access to the keys. A system could write keys to the key slots in the bootloader or in a TrustZone secure world. Then those keys could be used for crypto operations in Linux without ever exposing them. Key slots can be written to, but cannot be read from.

Even with keys stored in key slots, other keys may be used. For example, someone could do:
operation w/ key in slot 1
operation w/ key provided in descriptor
operation w/ key in slot 1

I don't think an LRU scheme would allow something like that.

Quoted 13 lines · Jay Monkman

That would be one use, but a more likely use would be to prevent access to the keys. A system could write keys to the key slots in the bootloader or in a TrustZone secure world. Then those keys could be used for crypto operations in Linux without ever exposing them. Key slots can be written to, but cannot be read from.

Even with keys stored in key slots, other keys may be used. For

example, someone could do:
operation w/ key in slot 1
operation w/ key provided in descriptor
operation w/ key in slot 1

Quoted 1 line

I don't think an LRU scheme would allow something like that.

In that case I would suggest using setkey with a length other than that of a valid AES key. For example, you could use a one- byte value to select the key slot.

Is this really a valid way to go about crypto -- introduce all kinds of obscure nuances into the API which are driver specific at best ?

Quoted 2 lines · Marek Vasut

Is this really a valid way to go about crypto -- introduce all kinds of obscure nuances into the API which are driver specific at best ?

So what do you suggest?

In general, it would probably make sense to add a flag to .setkey() to store the key in a keyslot. The keyslot allocation would be up to the driver. In case all keyslots would be full, the setkey() with the flag set would simply fail. This would imply you would need to have a counterpart function to .setkey() to free keyslots -- something like .unsetkey() .

Quoted 6 lines · Marek Vasut

In general, it would probably make sense to add a flag to .setkey() to store the key in a keyslot. The keyslot allocation would be up to the driver. In case all keyslots would be full, the setkey() with the flag set would simply fail. This would imply you would need to have a counterpart function to .setkey() to free keyslots -- something like .unsetkey() .

Changing setkey is going to cause too much churn. In any case I don't think these key slots should be written to by the kernel since the intention appears to be for entites outside the kernel to place secret keys in there that can then be used but not read by the kernel.

So as far as the kernel is concerned these are constant keys.

Therefore there should be no need for unsetkey.

So perhaps just add a new call setkey_slot that is optional and only needs to be implemented by drivers such as ccp.