Bill Sommerfeld wrote:
> On Fri, 2008-08-15 at 00:39 -0700, Garrett D'Amore wrote:
>
>> * performance -- the "slow path" causes packets to traverse PCI
>> busses 3 times, as noted, and certainly involves more complexity in the
>> paths (notably kcf scheduling of crypto gets involved).
>>
>
> The SCA4000 IPsec offload interface only accelerates 3DES; all the cool
> kids are now using AES. AES in software (not to mention the niagara 2
> crypto functional units) on current systems will be faster than 3DES
> offloaded through an SCA4000 using this interface and the data will also
> make only one traversal of an I/O bus.
>
Agreed. Recall, I'm in favor of this case. If Venus is EOL, then
simplifying our stack would be a good thing.
There may be folks who still have to use 3DES. (Though its been enough
years now that hopefully that number is approaching vanishingly small.
But then I suspect the number of customers who purchased SCA 4000 boards
was pretty small as well.)
> IMHO the primary motivation for building IPsec offload in the 2001/070
> style would be for assurance, not performance reasons:
> 1) to allow sensitive keying material to stay entirely within the
> boundary of the cryptographic device
> 2) to allow for clear separation between cleartext and ciphertext.
>
> 2001/070 was built purely as an acceleration interface with no
> possibility of keeping session keys material out of the hands of the
> host processor.
>
Yes. Session keys make it to the host driver.
At the time we did the work, the IPsec offload "inline" using these
primitives was substantially faster than the out-of-band approach using kcf.
>
>> * FIPS 140-2 compliance for SCA 4000? (Not that anyone would be
>> certifying SCA 4000 on post S10 releases)...
>>
>
> can you be more specific about why this might matter? the 2001/070
> interface involves the host IPsec passing raw (unwrapped) keying
> material to the driver.
>
The driver wraps the key material before passing it to the hardware.
Its goofy. Read more below.
>
>> * Potential (uncertain!) management considerations for secure key
>> management, although its unclear to me that SCA 4000 ever properly
>> secured IPsec session keys.
>>
>
> it's quite clear that 2001/070 interface used with IKE and IPsec ESP/AH
> required keying material to leave and then reenter the FIPS 140
> evaluation boundary of the card.
>
Ah, but there are some goofy things in the language of FIPS 140-2, where
if the keying material is "encrypted" before leaving the boundary, (and
no specification is given for the mode of encryption) then it is
considered OK. (Basically even very lame encryption with a fixed key
qualifies as seperation of key material and data into separate logical
channels.)
So the driver negotiates a wrapping key with the board, and the board
exports session keys wrapped, where the driver unwraps them.
From a security standpoint, it offers absolutely *no* improvement. But
it allowed for a FIPS evaluation.
I'm not sure this is the way the final product shipped, but it was the
way we were doing at the time I left the team. (I wrote that goofy
code, with grave misgivings about it at the time.)
>
>> (IKE should be able to use secure storage
>> for public keys via kcf, though.)
>>
>
> More importantly, IKE will continue to be able to use secure storage for
> the long-term private authentication/signature keys via kcf/PKCS#11 and
> either the SCA4000 or SCA6000 keystore.
>
Right.
-- Garrett
> - Bill
>
>
>
>
