> On Thu, 14 Jan 2021 at 11:25, Reshetova, Elena > <elena.reshetova@xxxxxxxxx> 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.
