| Message ID | 20201217172101.381772-1-daniele.alessandrelli@linux.intel.com |
|---|---|
| Headers | show |
| Series | Keem Bay OCS ECC crypto driver | expand |
On Thu, 17 Dec 2020 17:21:00 +0000, Daniele Alessandrelli wrote: > From: Prabhjot Khurana <prabhjot.khurana@intel.com> > > Add Keem Bay Offload and Crypto Subsystem (OCS) Elliptic Curve > Cryptography (ECC) device tree bindings. > > Signed-off-by: Prabhjot Khurana <prabhjot.khurana@intel.com> > Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> > --- > .../crypto/intel,keembay-ocs-ecc.yaml | 47 +++++++++++++++++++ > MAINTAINERS | 7 +++ > 2 files changed, 54 insertions(+) > create mode 100644 Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml > Reviewed-by: Rob Herring <robh@kernel.org>
> 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to > add SW fallback for P-192 in the driver, but the Intel Crypto team > (which, internally, has to approve any code involving cryptography) > advised against it, because they consider P-192 weak. As a result, the > driver is not passing crypto self-tests. Is there any possible solution > to this? Is it reasonable to change the self-tests to only test the > curves actually supported by the tested driver? (not fully sure how to do > that). An additional reason against the P-192 SW fallback is the fact that it can potentially trigger unsafe behavior which is not even "visible" to the end user of the ECC functionality. If I request (by my developer mistake) a P-192 weaker curve from ECC Keem Bay HW driver, it is much safer to return a "not supported" error that proceed behind my back with a SW code implementation making me believe that I am actually getting a HW-backed up functionality (since I don't think there is a way for me to check that I am using SW fallback). Best Regards, Elena
On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > (which, internally, has to approve any code involving cryptography) > > advised against it, because they consider P-192 weak. As a result, the > > driver is not passing crypto self-tests. Is there any possible solution > > to this? Is it reasonable to change the self-tests to only test the > > curves actually supported by the tested driver? (not fully sure how to do > > that). > > An additional reason against the P-192 SW fallback is the fact that it can > potentially trigger unsafe behavior which is not even "visible" to the end user > of the ECC functionality. If I request (by my developer mistake) a P-192 > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > "not supported" error that proceed behind my back with a SW code > implementation making me believe that I am actually getting a HW-backed up > functionality (since I don't think there is a way for me to check that I am using > SW fallback). Sorry, but if you break the Crypto API requirement then your driver isn't getting merged. Cheers,
> On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to > > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > > (which, internally, has to approve any code involving cryptography) > > > advised against it, because they consider P-192 weak. As a result, the > > > driver is not passing crypto self-tests. Is there any possible solution > > > to this? Is it reasonable to change the self-tests to only test the > > > curves actually supported by the tested driver? (not fully sure how to do > > > that). > > > > An additional reason against the P-192 SW fallback is the fact that it can > > potentially trigger unsafe behavior which is not even "visible" to the end user > > of the ECC functionality. If I request (by my developer mistake) a P-192 > > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > > "not supported" error that proceed behind my back with a SW code > > implementation making me believe that I am actually getting a HW-backed up > > functionality (since I don't think there is a way for me to check that I am using > > SW fallback). > > Sorry, but if you break the Crypto API requirement then your driver > isn't getting merged. But should not we think what behavior would make sense for good crypto drivers in future? As cryptography moves forward (especially for the post quantum era), we will have lengths for all existing algorithms increased (in addition to having a bunch of new ones), and we surely should not expect the new generation of HW drivers to implement the old/weaker lengths, so why there the requirement to support them? It is not a part of crypto API definition on what bit lengths should be supported, because it cannot be part of API to begin with since it is always changing parameter (algorithms and attacks develop all the time). Best Regards, Elena.
> > On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning > to > > > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > > > (which, internally, has to approve any code involving cryptography) > > > > advised against it, because they consider P-192 weak. As a result, the > > > > driver is not passing crypto self-tests. Is there any possible solution > > > > to this? Is it reasonable to change the self-tests to only test the > > > > curves actually supported by the tested driver? (not fully sure how to do > > > > that). > > > > > > An additional reason against the P-192 SW fallback is the fact that it can > > > potentially trigger unsafe behavior which is not even "visible" to the end user > > > of the ECC functionality. If I request (by my developer mistake) a P-192 > > > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > > > "not supported" error that proceed behind my back with a SW code > > > implementation making me believe that I am actually getting a HW-backed up > > > functionality (since I don't think there is a way for me to check that I am using > > > SW fallback). > > > > Sorry, but if you break the Crypto API requirement then your driver > > isn't getting merged. > > But should not we think what behavior would make sense for good crypto drivers in > future? > As cryptography moves forward (especially for the post quantum era), we will have > lengths for all existing algorithms increased (in addition to having a bunch of new > ones), > and we surely should not expect the new generation of HW drivers to implement > the old/weaker lengths, so why there the requirement to support them? It is not a > part of crypto API definition on what bit lengths should be supported, because it > cannot be part of API to begin with since it is always changing parameter (algorithms > and attacks > develop all the time). I would really appreciate, if someone helps us to understand here. Maybe there is a correct way to address this, but we just don't see it. The question is not even about this particular crypto driver and the fact whenever it gests merged or not, but the logic of the crypto API subsystem. As far as I understand the implementations that are provided by the specialized drivers (like our Keem Bay OCS ECC driver example here) have a higher priority vs. generic Implementations that exists in kernel, which makes sense because we expect these drivers (and the security HW they talk to) to provide both more efficient and more secure implementations than a pure SW implementation in kernel can do (even if it utilizes special instructions, like SIMD, AESNI, etc.). However, naturally these drivers are bound by what security HW can do, and if it does not support a certain size/param of the algorithm (P-192 curve in our case), it is pointless and wrong for them to reimplement what SW is already doing in kernel, so they should not do so and currently they re-direct to core kernel implementation. So far good. But now comes my biggest worry is that this redirection as far as I can see is *internal to driver itself*, i.e. it does a callback to these core functions from the driver code, which again, unless I misunderstand smth, leads to the fact that the end user gets P-192 curve ECC implementation from the core kernel that has been "promoted" to a highest priority (given that ECC KeemBay driver for example got priority 300 to begin with). So, if we say we have another HW Driver 'Foo', which happens to implement P-192 curves more securely, but happens to have a lower priority than ECC KeemBay driver, its implementation would never be chosen, but core kernel implementation will be used (via SW fallback internal to ECC Keem Bay driver). Another problem is that for a user of crypto API I don't see a way (and perhaps I am wrong here) to guarantee that all my calls to perform crypto operations will end up being performed on a security HW I want (maybe because this is the only thing I trust). It seems to be possible in theory, but in practice would require careful evaluation of a kernel setup and a sync between what end user requests and what driver can provide. Let me try to explain a potential scenario. Lets say we had an end user that used to ask for both P-192 and P-384 curve-based ECC operations and let's say we had a driver and security HW that implemented it. The end user made sure that this driver implementation is always preferred vs. other existing implementations. Now, time moves, a new security HW comes instead that only supports P-384, and the driver now has been updated to support P-192 via the SW fallback (like we are asked now). Now, how does an end user notice that when it asks for a P-192 based operations, his operations are not done in security HW anymore? The only way seems to be is to know that driver and security HW has been updated, algorithms and sizes changed, etc. It might take a while before the end user realizes this and for example stops using P-192 altogether, but what if this silent redirect by the driver actually breaks some security assumptions (side-channel resistance being one potential example) made by this end user? The consequences can be very bad. You might say: "this is the end user problem to verify this", but shouldn't we do smth to prevent or at least indicate such potential issues to them? Best Regards, Elena.
On Thu, 14 Jan 2021 at 11:25, Reshetova, Elena <elena.reshetova@intel.com> wrote: > > > > On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > > > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning > > to > > > > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > > > > (which, internally, has to approve any code involving cryptography) > > > > > advised against it, because they consider P-192 weak. As a result, the > > > > > driver is not passing crypto self-tests. Is there any possible solution > > > > > to this? Is it reasonable to change the self-tests to only test the > > > > > curves actually supported by the tested driver? (not fully sure how to do > > > > > that). > > > > > > > > An additional reason against the P-192 SW fallback is the fact that it can > > > > potentially trigger unsafe behavior which is not even "visible" to the end user > > > > of the ECC functionality. If I request (by my developer mistake) a P-192 > > > > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > > > > "not supported" error that proceed behind my back with a SW code > > > > implementation making me believe that I am actually getting a HW-backed up > > > > functionality (since I don't think there is a way for me to check that I am using > > > > SW fallback). > > > > > > Sorry, but if you break the Crypto API requirement then your driver > > > isn't getting merged. > > > > But should not we think what behavior would make sense for good crypto drivers in > > future? > > As cryptography moves forward (especially for the post quantum era), we will have > > lengths for all existing algorithms increased (in addition to having a bunch of new > > ones), > > and we surely should not expect the new generation of HW drivers to implement > > the old/weaker lengths, so why there the requirement to support them? It is not a > > part of crypto API definition on what bit lengths should be supported, because it > > cannot be part of API to begin with since it is always changing parameter (algorithms > > and attacks > > develop all the time). > > I would really appreciate, if someone helps us to understand here. Maybe there is a > correct way to address this, but we just don't see it. The question is not even about > this particular crypto driver and the fact whenever it gests merged or not, but the > logic of the crypto API subsystem. > > As far as I understand the implementations that are provided by the specialized drivers > (like our Keem Bay OCS ECC driver example here) have a higher priority vs. generic > Implementations that exists in kernel, which makes sense because we expect these drivers > (and the security HW they talk to) to provide both more efficient and more secure > implementations than a pure SW implementation in kernel can do (even if it utilizes special > instructions, like SIMD, AESNI, etc.). However, naturally these drivers are bound by > what security HW can do, and if it does not support a certain size/param of the algorithm > (P-192 curve in our case), it is pointless and wrong for them to reimplement what SW is > already doing in kernel, so they should not do so and currently they re-direct to core kernel > implementation. So far good. > > But now comes my biggest worry is that this redirection as far > as I can see is *internal to driver itself*, i.e. it does a callback to these core functions from the driver > code, which again, unless I misunderstand smth, leads to the fact that the end user gets > P-192 curve ECC implementation from the core kernel that has been "promoted" to a highest > priority (given that ECC KeemBay driver for example got priority 300 to begin with). So, if > we say we have another HW Driver 'Foo', which happens to implement P-192 curves more securely, > but happens to have a lower priority than ECC KeemBay driver, its implementation would never > be chosen, but core kernel implementation will be used (via SW fallback internal to ECC Keem > Bay driver). > No, this is incorrect. If you allocate a fallback algorithm in the correct way, the crypto API will resolve the allocation in the usual manner, and select whichever of the remaining implementations has the highest priority (provided that it does not require a fallback itself). > Another problem is that for a user of crypto API I don't see a way (and perhaps I am wrong here) > to guarantee that all my calls to perform crypto operations will end up being performed on a > security HW I want (maybe because this is the only thing I trust). It seems to be possible in theory, > but in practice would require careful evaluation of a kernel setup and a sync between what > end user requests and what driver can provide. Let me try to explain a potential scenario. > Lets say we had an end user that used to ask for both P-192 and P-384 curve-based ECC operations > and let's say we had a driver and security HW that implemented it. The end user made sure that > this driver implementation is always preferred vs. other existing implementations. Now, time moves, a new > security HW comes instead that only supports P-384, and the driver now has been updated to > support P-192 via the SW fallback (like we are asked now). > Now, how does an end user notice that when it asks for a P-192 based operations, his operations > are not done in security HW anymore? The only way seems to be > is to know that driver and security HW has been updated, algorithms and sizes changed, etc. > It might take a while before the end user realizes this and for example stops using P-192 altogether, > but what if this silent redirect by the driver actually breaks some security assumptions (side-channel > resistance being one potential example) made by this end user? The consequences can be very bad. > You might say: "this is the end user problem to verify this", but shouldn't we do smth to prevent or > at least indicate such potential issues to them? > I don't think it is possible at the API level to define rules that will always produce the most secure combination of drivers. The priority fields are only used to convey relative performance (which is already semantically murky, given the lack of distinction between hardware with a single queue vs software algorithms that can be executed by all CPUs in parallel). When it comes to comparative security, trustworthiness or robustness of implementations, it is simply left up to the user to blacklist modules that they prefer not to use. When fallback allocations are made in the correct way, the remaining available implementations will be used in priority order.
> On Thu, 14 Jan 2021 at 11:25, Reshetova, Elena > <elena.reshetova@intel.com> wrote: > > > > > > On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > > > > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were > planning > > > to > > > > > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > > > > > (which, internally, has to approve any code involving cryptography) > > > > > > advised against it, because they consider P-192 weak. As a result, the > > > > > > driver is not passing crypto self-tests. Is there any possible solution > > > > > > to this? Is it reasonable to change the self-tests to only test the > > > > > > curves actually supported by the tested driver? (not fully sure how to do > > > > > > that). > > > > > > > > > > An additional reason against the P-192 SW fallback is the fact that it can > > > > > potentially trigger unsafe behavior which is not even "visible" to the end user > > > > > of the ECC functionality. If I request (by my developer mistake) a P-192 > > > > > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > > > > > "not supported" error that proceed behind my back with a SW code > > > > > implementation making me believe that I am actually getting a HW-backed up > > > > > functionality (since I don't think there is a way for me to check that I am using > > > > > SW fallback). > > > > > > > > Sorry, but if you break the Crypto API requirement then your driver > > > > isn't getting merged. > > > > > > But should not we think what behavior would make sense for good crypto drivers > in > > > future? > > > As cryptography moves forward (especially for the post quantum era), we will > have > > > lengths for all existing algorithms increased (in addition to having a bunch of new > > > ones), > > > and we surely should not expect the new generation of HW drivers to implement > > > the old/weaker lengths, so why there the requirement to support them? It is not > a > > > part of crypto API definition on what bit lengths should be supported, because it > > > cannot be part of API to begin with since it is always changing parameter > (algorithms > > > and attacks > > > develop all the time). > > > > I would really appreciate, if someone helps us to understand here. Maybe there is a > > correct way to address this, but we just don't see it. The question is not even about > > this particular crypto driver and the fact whenever it gests merged or not, but the > > logic of the crypto API subsystem. > > > > As far as I understand the implementations that are provided by the specialized > drivers > > (like our Keem Bay OCS ECC driver example here) have a higher priority vs. generic > > Implementations that exists in kernel, which makes sense because we expect these > drivers > > (and the security HW they talk to) to provide both more efficient and more secure > > implementations than a pure SW implementation in kernel can do (even if it utilizes > special > > instructions, like SIMD, AESNI, etc.). However, naturally these drivers are bound by > > what security HW can do, and if it does not support a certain size/param of the > algorithm > > (P-192 curve in our case), it is pointless and wrong for them to reimplement what > SW is > > already doing in kernel, so they should not do so and currently they re-direct to > core kernel > > implementation. So far good. > > > > But now comes my biggest worry is that this redirection as far > > as I can see is *internal to driver itself*, i.e. it does a callback to these core > functions from the driver > > code, which again, unless I misunderstand smth, leads to the fact that the end user > gets > > P-192 curve ECC implementation from the core kernel that has been "promoted" > to a highest > > priority (given that ECC KeemBay driver for example got priority 300 to begin with). > So, if > > we say we have another HW Driver 'Foo', which happens to implement P-192 > curves more securely, > > but happens to have a lower priority than ECC KeemBay driver, its implementation > would never > > be chosen, but core kernel implementation will be used (via SW fallback internal to > ECC Keem > > Bay driver). > > > > No, this is incorrect. If you allocate a fallback algorithm in the > correct way, the crypto API will resolve the allocation in the usual > manner, and select whichever of the remaining implementations has the > highest priority (provided that it does not require a fallback > itself). Thank you very much Ard for the important correction here! See below if I got it now correctly to the end for the use case in question. > > > Another problem is that for a user of crypto API I don't see a way (and perhaps I > am wrong here) > > to guarantee that all my calls to perform crypto operations will end up being > performed on a > > security HW I want (maybe because this is the only thing I trust). It seems to be > possible in theory, > > but in practice would require careful evaluation of a kernel setup and a sync > between what > > end user requests and what driver can provide. Let me try to explain a potential > scenario. > > Lets say we had an end user that used to ask for both P-192 and P-384 curve-based > ECC operations > > and let's say we had a driver and security HW that implemented it. The end user > made sure that > > this driver implementation is always preferred vs. other existing implementations. > Now, time moves, a new > > security HW comes instead that only supports P-384, and the driver now has been > updated to > > support P-192 via the SW fallback (like we are asked now). > > Now, how does an end user notice that when it asks for a P-192 based operations, > his operations > > are not done in security HW anymore? The only way seems to be > > is to know that driver and security HW has been updated, algorithms and sizes > changed, etc. > > It might take a while before the end user realizes this and for example stops using > P-192 altogether, > > but what if this silent redirect by the driver actually breaks some security > assumptions (side-channel > > resistance being one potential example) made by this end user? The consequences > can be very bad. > > You might say: "this is the end user problem to verify this", but shouldn't we do > smth to prevent or > > at least indicate such potential issues to them? > > > > I don't think it is possible at the API level to define rules that > will always produce the most secure combination of drivers. The > priority fields are only used to convey relative performance (which is > already semantically murky, given the lack of distinction between > hardware with a single queue vs software algorithms that can be > executed by all CPUs in parallel). > > When it comes to comparative security, trustworthiness or robustness > of implementations, it is simply left up to the user to blacklist > modules that they prefer not to use. When fallback allocations are > made in the correct way, the remaining available implementations will > be used in priority order. So, let me see if I understand the full picture correctly now and how to utilize the blacklisting of modules as a user. Suppose I want to blacklist everything but my OSC driver module. So, if I am as a user refer to a specific driver implementation using a unique driver name (ecdh-keembay-ocs in our case), then regardless of the fact that a driver implements this SW fallback for P-192 curve, if I am as a user to ask for P-192 curve (or any other param that results in SW fallback), I will be notified that this requested implementation does not provide it? Best Regards, Elena.
On Mon, 18 Jan 2021 at 12:55, Reshetova, Elena <elena.reshetova@intel.com> wrote: > > > On Thu, 14 Jan 2021 at 11:25, Reshetova, Elena > > <elena.reshetova@intel.com> wrote: > > > > > > > > On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > > > > > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were > > planning > > > > to > > > > > > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > > > > > > (which, internally, has to approve any code involving cryptography) > > > > > > > advised against it, because they consider P-192 weak. As a result, the > > > > > > > driver is not passing crypto self-tests. Is there any possible solution > > > > > > > to this? Is it reasonable to change the self-tests to only test the > > > > > > > curves actually supported by the tested driver? (not fully sure how to do > > > > > > > that). > > > > > > > > > > > > An additional reason against the P-192 SW fallback is the fact that it can > > > > > > potentially trigger unsafe behavior which is not even "visible" to the end user > > > > > > of the ECC functionality. If I request (by my developer mistake) a P-192 > > > > > > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > > > > > > "not supported" error that proceed behind my back with a SW code > > > > > > implementation making me believe that I am actually getting a HW-backed up > > > > > > functionality (since I don't think there is a way for me to check that I am using > > > > > > SW fallback). > > > > > > > > > > Sorry, but if you break the Crypto API requirement then your driver > > > > > isn't getting merged. > > > > > > > > But should not we think what behavior would make sense for good crypto drivers > > in > > > > future? > > > > As cryptography moves forward (especially for the post quantum era), we will > > have > > > > lengths for all existing algorithms increased (in addition to having a bunch of new > > > > ones), > > > > and we surely should not expect the new generation of HW drivers to implement > > > > the old/weaker lengths, so why there the requirement to support them? It is not > > a > > > > part of crypto API definition on what bit lengths should be supported, because it > > > > cannot be part of API to begin with since it is always changing parameter > > (algorithms > > > > and attacks > > > > develop all the time). > > > > > > I would really appreciate, if someone helps us to understand here. Maybe there is a > > > correct way to address this, but we just don't see it. The question is not even about > > > this particular crypto driver and the fact whenever it gests merged or not, but the > > > logic of the crypto API subsystem. > > > > > > As far as I understand the implementations that are provided by the specialized > > drivers > > > (like our Keem Bay OCS ECC driver example here) have a higher priority vs. generic > > > Implementations that exists in kernel, which makes sense because we expect these > > drivers > > > (and the security HW they talk to) to provide both more efficient and more secure > > > implementations than a pure SW implementation in kernel can do (even if it utilizes > > special > > > instructions, like SIMD, AESNI, etc.). However, naturally these drivers are bound by > > > what security HW can do, and if it does not support a certain size/param of the > > algorithm > > > (P-192 curve in our case), it is pointless and wrong for them to reimplement what > > SW is > > > already doing in kernel, so they should not do so and currently they re-direct to > > core kernel > > > implementation. So far good. > > > > > > But now comes my biggest worry is that this redirection as far > > > as I can see is *internal to driver itself*, i.e. it does a callback to these core > > functions from the driver > > > code, which again, unless I misunderstand smth, leads to the fact that the end user > > gets > > > P-192 curve ECC implementation from the core kernel that has been "promoted" > > to a highest > > > priority (given that ECC KeemBay driver for example got priority 300 to begin with). > > So, if > > > we say we have another HW Driver 'Foo', which happens to implement P-192 > > curves more securely, > > > but happens to have a lower priority than ECC KeemBay driver, its implementation > > would never > > > be chosen, but core kernel implementation will be used (via SW fallback internal to > > ECC Keem > > > Bay driver). > > > > > > > No, this is incorrect. If you allocate a fallback algorithm in the > > correct way, the crypto API will resolve the allocation in the usual > > manner, and select whichever of the remaining implementations has the > > highest priority (provided that it does not require a fallback > > itself). > > Thank you very much Ard for the important correction here! > See below if I got it now correctly to the end for the use case in question. > > > > > > Another problem is that for a user of crypto API I don't see a way (and perhaps I > > am wrong here) > > > to guarantee that all my calls to perform crypto operations will end up being > > performed on a > > > security HW I want (maybe because this is the only thing I trust). It seems to be > > possible in theory, > > > but in practice would require careful evaluation of a kernel setup and a sync > > between what > > > end user requests and what driver can provide. Let me try to explain a potential > > scenario. > > > Lets say we had an end user that used to ask for both P-192 and P-384 curve-based > > ECC operations > > > and let's say we had a driver and security HW that implemented it. The end user > > made sure that > > > this driver implementation is always preferred vs. other existing implementations. > > Now, time moves, a new > > > security HW comes instead that only supports P-384, and the driver now has been > > updated to > > > support P-192 via the SW fallback (like we are asked now). > > > Now, how does an end user notice that when it asks for a P-192 based operations, > > his operations > > > are not done in security HW anymore? The only way seems to be > > > is to know that driver and security HW has been updated, algorithms and sizes > > changed, etc. > > > It might take a while before the end user realizes this and for example stops using > > P-192 altogether, > > > but what if this silent redirect by the driver actually breaks some security > > assumptions (side-channel > > > resistance being one potential example) made by this end user? The consequences > > can be very bad. > > > You might say: "this is the end user problem to verify this", but shouldn't we do > > smth to prevent or > > > at least indicate such potential issues to them? > > > > > > > I don't think it is possible at the API level to define rules that > > will always produce the most secure combination of drivers. The > > priority fields are only used to convey relative performance (which is > > already semantically murky, given the lack of distinction between > > hardware with a single queue vs software algorithms that can be > > executed by all CPUs in parallel). > > > > When it comes to comparative security, trustworthiness or robustness > > of implementations, it is simply left up to the user to blacklist > > modules that they prefer not to use. When fallback allocations are > > made in the correct way, the remaining available implementations will > > be used in priority order. > > So, let me see if I understand the full picture correctly now and how to utilize > the blacklisting of modules as a user. Suppose I want to blacklist everything but > my OSC driver module. So, if I am as a user refer to a specific driver implementation > using a unique driver name (ecdh-keembay-ocs in our case), then regardless of the > fact that a driver implements this SW fallback for P-192 curve, if I am as a user to > ask for P-192 curve (or any other param that results in SW fallback), I will be notified > that this requested implementation does not provide it? > This is rather unusual compared with how the crypto API is typically used, but if this is really what you want to implement, you can do so by: - having a "ecdh" implementation that implements the entire range, and uses a fallback for curves that it does not implement - export the same implementation again as "ecdh" and with a known driver name "ecdh-keembay-ocs", but with a slightly lower priority, and in this case, return an error when the unimplemented curve is requested. That way, you fully adhere to the API, by providing implementations of all curves by default. And if a user requests "ecdh-keembay-ocs" explicitly, it will not be able to use the P192 curve inadvertently. But policing which curves are secure and which are not is really not the job of the API. We have implementations of MD5 and RC4 in the kernel that we would *love* to remove but we simply cannot do so as long as they are still being used. The same applies to P192: we simply cannot fail requests for that curve for use cases that were previously deemed valid. It is perfectly reasonable to omit the implementation from your hardware, but banning its use outright on the grounds that is no longer secure conflicts with our requirement not to break existing use cases.
> On Mon, 18 Jan 2021 at 12:55, Reshetova, Elena > <elena.reshetova@intel.com> wrote: > > > > > On Thu, 14 Jan 2021 at 11:25, Reshetova, Elena > > > <elena.reshetova@intel.com> wrote: > > > > > > > > > > On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote: > > > > > > > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were > > > planning > > > > > to > > > > > > > > add SW fallback for P-192 in the driver, but the Intel Crypto team > > > > > > > > (which, internally, has to approve any code involving cryptography) > > > > > > > > advised against it, because they consider P-192 weak. As a result, the > > > > > > > > driver is not passing crypto self-tests. Is there any possible solution > > > > > > > > to this? Is it reasonable to change the self-tests to only test the > > > > > > > > curves actually supported by the tested driver? (not fully sure how to > do > > > > > > > > that). > > > > > > > > > > > > > > An additional reason against the P-192 SW fallback is the fact that it can > > > > > > > potentially trigger unsafe behavior which is not even "visible" to the end > user > > > > > > > of the ECC functionality. If I request (by my developer mistake) a P-192 > > > > > > > weaker curve from ECC Keem Bay HW driver, it is much safer to return a > > > > > > > "not supported" error that proceed behind my back with a SW code > > > > > > > implementation making me believe that I am actually getting a HW- > backed up > > > > > > > functionality (since I don't think there is a way for me to check that I am > using > > > > > > > SW fallback). > > > > > > > > > > > > Sorry, but if you break the Crypto API requirement then your driver > > > > > > isn't getting merged. > > > > > > > > > > But should not we think what behavior would make sense for good crypto > drivers > > > in > > > > > future? > > > > > As cryptography moves forward (especially for the post quantum era), we will > > > have > > > > > lengths for all existing algorithms increased (in addition to having a bunch of > new > > > > > ones), > > > > > and we surely should not expect the new generation of HW drivers to > implement > > > > > the old/weaker lengths, so why there the requirement to support them? It is > not > > > a > > > > > part of crypto API definition on what bit lengths should be supported, > because it > > > > > cannot be part of API to begin with since it is always changing parameter > > > (algorithms > > > > > and attacks > > > > > develop all the time). > > > > > > > > I would really appreciate, if someone helps us to understand here. Maybe there > is a > > > > correct way to address this, but we just don't see it. The question is not even > about > > > > this particular crypto driver and the fact whenever it gests merged or not, but > the > > > > logic of the crypto API subsystem. > > > > > > > > As far as I understand the implementations that are provided by the specialized > > > drivers > > > > (like our Keem Bay OCS ECC driver example here) have a higher priority vs. > generic > > > > Implementations that exists in kernel, which makes sense because we expect > these > > > drivers > > > > (and the security HW they talk to) to provide both more efficient and more > secure > > > > implementations than a pure SW implementation in kernel can do (even if it > utilizes > > > special > > > > instructions, like SIMD, AESNI, etc.). However, naturally these drivers are bound > by > > > > what security HW can do, and if it does not support a certain size/param of the > > > algorithm > > > > (P-192 curve in our case), it is pointless and wrong for them to reimplement > what > > > SW is > > > > already doing in kernel, so they should not do so and currently they re-direct to > > > core kernel > > > > implementation. So far good. > > > > > > > > But now comes my biggest worry is that this redirection as far > > > > as I can see is *internal to driver itself*, i.e. it does a callback to these core > > > functions from the driver > > > > code, which again, unless I misunderstand smth, leads to the fact that the end > user > > > gets > > > > P-192 curve ECC implementation from the core kernel that has been > "promoted" > > > to a highest > > > > priority (given that ECC KeemBay driver for example got priority 300 to begin > with). > > > So, if > > > > we say we have another HW Driver 'Foo', which happens to implement P-192 > > > curves more securely, > > > > but happens to have a lower priority than ECC KeemBay driver, its > implementation > > > would never > > > > be chosen, but core kernel implementation will be used (via SW fallback > internal to > > > ECC Keem > > > > Bay driver). > > > > > > > > > > No, this is incorrect. If you allocate a fallback algorithm in the > > > correct way, the crypto API will resolve the allocation in the usual > > > manner, and select whichever of the remaining implementations has the > > > highest priority (provided that it does not require a fallback > > > itself). > > > > Thank you very much Ard for the important correction here! > > See below if I got it now correctly to the end for the use case in question. > > > > > > > > > Another problem is that for a user of crypto API I don't see a way (and perhaps I > > > am wrong here) > > > > to guarantee that all my calls to perform crypto operations will end up being > > > performed on a > > > > security HW I want (maybe because this is the only thing I trust). It seems to be > > > possible in theory, > > > > but in practice would require careful evaluation of a kernel setup and a sync > > > between what > > > > end user requests and what driver can provide. Let me try to explain a potential > > > scenario. > > > > Lets say we had an end user that used to ask for both P-192 and P-384 curve- > based > > > ECC operations > > > > and let's say we had a driver and security HW that implemented it. The end user > > > made sure that > > > > this driver implementation is always preferred vs. other existing > implementations. > > > Now, time moves, a new > > > > security HW comes instead that only supports P-384, and the driver now has > been > > > updated to > > > > support P-192 via the SW fallback (like we are asked now). > > > > Now, how does an end user notice that when it asks for a P-192 based > operations, > > > his operations > > > > are not done in security HW anymore? The only way seems to be > > > > is to know that driver and security HW has been updated, algorithms and sizes > > > changed, etc. > > > > It might take a while before the end user realizes this and for example stops > using > > > P-192 altogether, > > > > but what if this silent redirect by the driver actually breaks some security > > > assumptions (side-channel > > > > resistance being one potential example) made by this end user? The > consequences > > > can be very bad. > > > > You might say: "this is the end user problem to verify this", but shouldn't we do > > > smth to prevent or > > > > at least indicate such potential issues to them? > > > > > > > > > > I don't think it is possible at the API level to define rules that > > > will always produce the most secure combination of drivers. The > > > priority fields are only used to convey relative performance (which is > > > already semantically murky, given the lack of distinction between > > > hardware with a single queue vs software algorithms that can be > > > executed by all CPUs in parallel). > > > > > > When it comes to comparative security, trustworthiness or robustness > > > of implementations, it is simply left up to the user to blacklist > > > modules that they prefer not to use. When fallback allocations are > > > made in the correct way, the remaining available implementations will > > > be used in priority order. > > > > So, let me see if I understand the full picture correctly now and how to utilize > > the blacklisting of modules as a user. Suppose I want to blacklist everything but > > my OSC driver module. So, if I am as a user refer to a specific driver > implementation > > using a unique driver name (ecdh-keembay-ocs in our case), then regardless of the > > fact that a driver implements this SW fallback for P-192 curve, if I am as a user to > > ask for P-192 curve (or any other param that results in SW fallback), I will be > notified > > that this requested implementation does not provide it? > > > > This is rather unusual compared with how the crypto API is typically > used, The interesting part here is that I think the use case I am describing is pretty generic, it is strange to see why noone has raised this before. One would think that this is the purpose of having these more secure crypto HW implementations supported via drivers to make sure that the users that care about high-grade security actually get what they expect and the risk of mistakes is minimized. but if this is really what you want to implement, you can do so > by: > - having a "ecdh" implementation that implements the entire range, and > uses a fallback for curves that it does not implement > - export the same implementation again as "ecdh" and with a known > driver name "ecdh-keembay-ocs", but with a slightly lower priority, > and in this case, return an error when the unimplemented curve is > requested. > > That way, you fully adhere to the API, by providing implementations of > all curves by default. And if a user requests "ecdh-keembay-ocs" > explicitly, it will not be able to use the P192 curve inadvertently. Thank you very much Ard for this explanation! We will see how such implementation definition would look in practice first before thinking on the way to proceed. It might end up looking strange and confusing, and if so, it would at the end destroy the original idea to make "it simple and secure for the driver users to use the provided functionality". I have not seen this being done at all before at any existing crypto drivers, that's why I was thinking this is not supported to begin with. > > But policing which curves are secure and which are not is really not > the job of the API. We have implementations of MD5 and RC4 in the > kernel that we would *love* to remove but we simply cannot do so as > long as they are still being used. The same applies to P192: we simply > cannot fail requests for that curve for use cases that were previously > deemed valid. It is perfectly reasonable to omit the implementation > from your hardware, but banning its use outright on the grounds that > is no longer secure conflicts with our requirement not to break > existing use cases. I agree with the above logic. In the light that the crypto API is a toolbox for the crypto and not the security subsystem that aims to make any guarantees on the end security properties it all makes sense. I guess I was only asking if this toolbox can help its users to minimize potential mistakes and be configurable enough to support different usage scenarios. But if the above works, I guess it supports it, just hope the end declaration is not too messy to create other (different) usage problems. Best Regards, Elena.
Hi Ard, Thank you very much for your valuable feedback. On Mon, 2021-01-18 at 13:09 +0100, Ard Biesheuvel wrote: > This is rather unusual compared with how the crypto API is typically > used, but if this is really what you want to implement, you can do so > by: > - having a "ecdh" implementation that implements the entire range, and > uses a fallback for curves that it does not implement > - export the same implementation again as "ecdh" and with a known > driver name "ecdh-keembay-ocs", but with a slightly lower priority, > and in this case, return an error when the unimplemented curve is > requested. > > That way, you fully adhere to the API, by providing implementations of > all curves by default. And if a user requests "ecdh-keembay-ocs" > explicitly, it will not be able to use the P192 curve inadvertently. I tried to implement this, but it looks like the driver name is mandatory, so I specified one also for the first implementation. Basically I defined two 'struct kpp_alg' variables; both with cra_name = "ecdh", but with different 'cra_driver_name' (one with cra_driver_name = "ecdh-keembay-ocs-fallback" and the other one with cra_driver_name = "ecdh-keembay-ocs"). Is this what you were suggesting? Anyway, that works (i.e., 'ecdh-keembay-ocs' returns an error when the unimplemented curve is requested; while 'ecdh-keembay-ocs' and 'ecdh' work fine with any curve), but I have to set the priority of 'ecdh- keembay-ocs' to something lower than the 'ecdh_generic' priority. Otherwise the implementation with fallback ends up using my "ecdh- keembay-ocs" as fallback (so it ends up using a fallback that still does not support the P-192 curve). Also, the implementation without fallback is still failing crypto self- tests (as expected I guess). Therefore, I tried with a slightly different solution. Still two implementations, but with different cra_names (one with cra_name = "ecdh" and the other one with cra_name = "ecdh-keembay"). This solution seems to be working, since, the "ecdh-keembay" is not tested by the self tests and is not picked up as fallback for "ecdh" (since, if I understand it correctly, it's like if I'm defining a new kind of kpp algorithm), but it's still picked when calling crypto_alloc_kpp("ecdh- keembay"). Does this second solution looks okay to you? Or does it have some pitfall that I'm missing? Regards, Daniele
On Thu, 2021-01-21 at 10:52 +0100, Ard Biesheuvel wrote: > On Wed, 20 Jan 2021 at 20:00, Alessandrelli, Daniele > <daniele.alessandrelli@intel.com> wrote: > > Hi Ard, > > > > Thank you very much for your valuable feedback. > > > > On Mon, 2021-01-18 at 13:09 +0100, Ard Biesheuvel wrote: > > > This is rather unusual compared with how the crypto API is > > > typically > > > used, but if this is really what you want to implement, you can > > > do so > > > by: > > > - having a "ecdh" implementation that implements the entire > > > range, and > > > uses a fallback for curves that it does not implement > > > - export the same implementation again as "ecdh" and with a known > > > driver name "ecdh-keembay-ocs", but with a slightly lower > > > priority, > > > and in this case, return an error when the unimplemented curve is > > > requested. > > > > > > That way, you fully adhere to the API, by providing > > > implementations of > > > all curves by default. And if a user requests "ecdh-keembay-ocs" > > > explicitly, it will not be able to use the P192 curve > > > inadvertently. > > > > I tried to implement this, but it looks like the driver name is > > mandatory, so I specified one also for the first implementation. > > > > Basically I defined two 'struct kpp_alg' variables; both with > > cra_name > > = "ecdh", but with different 'cra_driver_name' (one with > > cra_driver_name = "ecdh-keembay-ocs-fallback" and the other one > > with > > cra_driver_name = "ecdh-keembay-ocs"). > > > > Is this what you were suggesting? > > > > Anyway, that works (i.e., 'ecdh-keembay-ocs' returns an error when > > the > > unimplemented curve is requested; while 'ecdh-keembay-ocs' and > > 'ecdh' > > work fine with any curve), but I have to set the priority of 'ecdh- > > keembay-ocs' to something lower than the 'ecdh_generic' priority. > > Otherwise the implementation with fallback ends up using my "ecdh- > > keembay-ocs" as fallback (so it ends up using a fallback that still > > does not support the P-192 curve). > > > > Also, the implementation without fallback is still failing crypto > > self- > > tests (as expected I guess). > > > > Therefore, I tried with a slightly different solution. Still two > > implementations, but with different cra_names (one with cra_name = > > "ecdh" and the other one with cra_name = "ecdh-keembay"). This > > solution > > seems to be working, since, the "ecdh-keembay" is not tested by the > > self tests and is not picked up as fallback for "ecdh" (since, if I > > understand it correctly, it's like if I'm defining a new kind of > > kpp > > algorithm), but it's still picked when calling > > crypto_alloc_kpp("ecdh- > > keembay"). > > > > Does this second solution looks okay to you? Or does it have some > > pitfall that I'm missing? > > > > You should set the CRYPTO_ALG_NEED_FALLBACK flag on both > implementations, to ensure that neither of them are considered as > fallbacks themselves. Thanks again! I was setting that flag only for the first implementation (the one with fallback), but I see now how it's needed for the second one as well. With that, the second implementation (i.e., the one without fallback) is not used anymore as a fallback for the first one. As expected, the second implementation does not pass self-tests and crypto_alloc_kpp() returns -ELIBBAD when trying to allocate it, but I've seen that I can avoid the error (and have it allocated properly) by passing the CRYPTO_ALG_TESTED flag in the 'type' argument, like below: crypto_alloc_kpp("ecdh-keembay-ocs", CRYPTO_ALG_TESTED, 0); Is that the right way to tell crypto_alloc_kpp() that we are fine using an implementation that fails self-tests?
On Thu, Jan 21, 2021 at 04:13:51PM +0000, Alessandrelli, Daniele wrote: > > As expected, the second implementation does not pass self-tests and > crypto_alloc_kpp() returns -ELIBBAD when trying to allocate it, but > I've seen that I can avoid the error (and have it allocated properly) > by passing the CRYPTO_ALG_TESTED flag in the 'type' argument, like > below: Did you set your algorithm's name to ecdh? I think Ard was suggesting you to not do that. As long as you're not using the same name as a recognised algorithm, then you won't need to pass any self-tests at all. Cheers,
On Fri, 2021-01-22 at 07:02 +1100, Herbert Xu wrote: > On Thu, Jan 21, 2021 at 04:13:51PM +0000, Alessandrelli, Daniele > wrote: > > As expected, the second implementation does not pass self-tests and > > crypto_alloc_kpp() returns -ELIBBAD when trying to allocate it, but > > I've seen that I can avoid the error (and have it allocated > > properly) > > by passing the CRYPTO_ALG_TESTED flag in the 'type' argument, like > > below: > > Did you set your algorithm's name to ecdh? I think Ard was suggesting > you to not do that. As long as you're not using the same name as a > recognised algorithm, then you won't need to pass any self-tests at > all. > Oh, looks like I misunderstood Ard suggestion. I will change the second implementation to use a different algorithm name (cra_name), something like 'ecdh-keembay-ocs'. Thanks, Daniele
Hi, I'm posting this patch series as RFC since there are a few open points on which I'd like to have the opinion of the crypto maintainers and the rest of kernel community. The patch series adds the Intel Keem Bay OCS ECC crypto driver, which enables hardware-accelerated ECDH on the Intel Keem Bay SoC. The open points are the followings: 1. The OCS ECC HW supports the NIST P-384 curve, which, however, is not supported by Linux ECDH software implementation ('crypto/ecdh.c'). Support for P-384 is added to the driver anyway by reserving a curve id for P-384 in 'include/crypto/ecdh.h' and defining the cure parameters in 'drivers/crypto/keembay/ocs-ecc-curve-defs.h'. Is this reasonable? 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to add SW fallback for P-192 in the driver, but the Intel Crypto team (which, internally, has to approve any code involving cryptography) advised against it, because they consider P-192 weak. As a result, the driver is not passing crypto self-tests. Is there any possible solution to this? Is it reasonable to change the self-tests to only test the curves actually supported by the tested driver? (not fully sure how to do that). 3. Another request from our crypto team was to make private key generation optional in the driver, since they advice against automatic key generation. As a result, the driver passes the P-256 self test only when CONFIG_CRYPTO_DEV_KEEMBAY_OCS_ECDH_GEN_PRIV_KEY_SUPPORT=y. Is that acceptable? Daniele Alessandrelli (2): crypto: ecc - Move ecc.h to include/crypto/internal crypto: ecc - Export additional helper functions Prabhjot Khurana (4): crypto: engine - Add KPP Support to Crypto Engine crypto: ecdh - Add Curve ID for NIST P-384 dt-bindings: crypto: Add Keem Bay ECC bindings crypto: keembay-ocs-ecc - Add Keem Bay OCS ECC Driver Documentation/crypto/crypto_engine.rst | 4 + .../crypto/intel,keembay-ocs-ecc.yaml | 47 + MAINTAINERS | 11 + crypto/crypto_engine.c | 27 + crypto/ecc.c | 18 +- crypto/ecdh.c | 2 +- crypto/ecrdsa.c | 2 +- crypto/ecrdsa_defs.h | 2 +- drivers/crypto/keembay/Kconfig | 31 + drivers/crypto/keembay/Makefile | 2 + drivers/crypto/keembay/keembay-ocs-ecc.c | 1003 +++++++++++++++++ drivers/crypto/keembay/ocs-ecc-curve-defs.h | 68 ++ include/crypto/ecdh.h | 1 + include/crypto/engine.h | 5 + {crypto => include/crypto/internal}/ecc.h | 44 + 15 files changed, 1257 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml create mode 100644 drivers/crypto/keembay/keembay-ocs-ecc.c create mode 100644 drivers/crypto/keembay/ocs-ecc-curve-defs.h rename {crypto => include/crypto/internal}/ecc.h (87%) base-commit: 90cc8cf2d1ab87d708ebc311ac104ccbbefad9fc