Why are we using OpenSSL for this instead of PKCS#11? Is SunSSH already
using OpenSSL (without engine support)?
If all things were equal (and I'm not saying they are), I'd think direct
access to PKCS#11 would be preferable, since it would reduce layering
induced overhead, and might offer additional configuration options.
One of the PKCS#11 configuration options that might be really cool to
have, for example, would be support for PKCS#11 secure key management.
(I.e. allow me to store my private keys securely in a FIPS-140-2
compliant crypto device such as SCA 6000.) It isn't clear to me that
this is easy (or feasible) with an OpenSSL layered approach.
It seems like this project is only offer the acceleration benefit for
hardware crypto, and not offering any key handling improvements, right?
Also, what are the "compatibility" concerns of the new configuration
file directive? What will happen to other open source implementations
of SSH when they see the same directive (such as when sharing a home
directory via NFS with Linux or FreeBSD systems)?
Finally, might it not be a better choice to avoid hardcoding the notion
of OpenSSL into the configuration file syntax? Perhaps something more
generic, such as "UseHardwareOffload" or somesuch might be better,
especially if the software might one day be changed to use a different
crypto backend (such as PKCS#11.)
-- Garrett
Darren J Moffat wrote:
> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>
> SunSSH with the OpenSSL PKCS#11 engine support
>
> 1.2. Name of Document Author/Supplier:
>
> Jan Pechanec
>
> 1.3. Date of This Document:
>
> 12/08/08
>
> 1.4. Name of Major Document Customer(s)/Consumer(s):
>
> 1.4.2. The ARC(s) you expect to review your project:
>
> PSARC
>
> 1.4.4. The name of your business unit:
>
> Security
>
> 1.5. Email Aliases:
> 1.5.1. Responsible Manager: Anup.Sekhar at Sun.COM
> 1.5.2. Responsible Engineer: Jan.Pechanec at Sun.COM
> 1.5.3. Marketing Manager: Mark.Thacker at Sun.COM
> 1.5.4. Interest List: security-discuss at opensolaris.org
>
>
> 2. Project Summary
> 2.1. Project Description:
>
> SunSSH is a single threaded and CPU intensive application with regard to
> the symmetric encryption algorithms. If run on a machine with relatively
> slow CPU(s) the user experience is that the data transfer is very slow.
> Such machine is UltraSPARC T2, for example. The answer to this issue is
> to use crypto hardware accelerators through the OpenSSL API that SunSSH
> already uses.
>
> This project adds code that allows SunSSH to use the PKCS#11 engine that
> is integrated into OpenSSL version shipped with Solaris. The engine will
> be set on by default so that users get the speed-up without any need to
> configure it. On machines with no crypto HW accelerators the speed of
> the data transfer will stay the same. There will be a way to switch off
> any offloading of crypto operations to the PKCS#11 engine using a new
> option, UseOpenSSLEngine.
>
> 2.2. Risks and Assumptions:
>
> None.
>
>
> 3. Business Summary
> 3.1. Problem Area:
>
> Customers consider SunSSH slow on Niagara 2 machine or consider Niagara
> 2 machines slow in general when they test the data transfer speed with
> SunSSH.
>
> 3.3. Business Justification:
>
> People who try out UltraSPARC T2 machines very often test the machine by
> transfering a large amount of data over SSH, expecting it to perform
> reasonably fast due to an expected use of HW accelerators. However, the
> reality is that it's significantly slower than expected. For example,
> the data transfer speed is 2.5x slower than between 2 AMD64 machines
> with 2.4GHz CPUs. As a result of this test, many people consider
> machines based on UltraSPARC T2 CPU slow in general.
>
> 4. Technical Description:
> 4.1. Details:
>
> SunSSH will load the PKCS#11 engine based on the configuration option
> UseOpenSSLEngine. This option will be "yes" by default. The reason for
> introducing this option is that possible bug in a driver, a 3rd party
> crypto card for example, could cause SunSSH to be unusable. In that
> case, setting UseOpenSSLEngine to "no" will rollback to native OpenSSL
> crypto code only.
>
> Since we ship OpenSSL with one engine only we introduce just one new
> option. If we offer more engines in the future suitable for the use with
> SunSSH, we will introduce another option, probably called OpenSSLEngine,
> to hold the specific engine name.
>
> This project speeds up the data transfer on UltraSPARC T2 by 2.5x. To
> avoid any confusion, that means that a data transfer that took 50
> seconds on UltraSPARC T2 takes 20 seconds now on the same machine.
> That's similar to a data transfer speed between 2 AMD64 2.4GHz machines.
> It doesn't matter whether the data is transfered over ssh(1) through a
> pipe (dd if=... | ssh ... "cat > xxx"), using scp(1) or sftp(1). All
> cases are accelerated; note that both scp(1) and sftp(1) use ssh(1) as a
> transport layer.
>
> 4.2. Bug/RFE Number(s):
>
> the project implements this RFE:
>
> 6445288 ssh needs to be OpenSSL engine aware
>
> I'll fix following SunSSH CRs as part of this project:
>
> 6709963 SunSSH leaks memory during initialization
> 6687401 ssh monitor shouldn't try to log remote IP when child
> closed the pipe
> 6696629 sshd should remove alarm signal handler after
> authentication
>
> and these which were filed against the Cryptographic Framework:
>
> 6674088 userland threshold for hw offloading makes it difficult
> for SSL and SSH protocols
> 6728450 6708125 prevents parent to use the Crypto Framework
> after the fork(2)
>
> 4.5. Interfaces:
>
> - we do NOT add any new command line option.
>
> - we add new UseOpenSSLEngine option keyword to both sshd and ssh (for
> use in sshd_config and ssh_config configuration files, respectively,
> or with "-o" command line option).
>
> 4.6. Doc Impact:
>
> Manual pages for sshd_config(5) and ssh_config(5) will be changed. The
> draft for the new option section follows:
>
>
> UseOpenSSLEngine
>
> Specifies whether sshd should use the OpenSSL PKCS#11
> engine for offloading cryptographic operations to the
> Cryptographic Framework. Cryptographic operations are
> accelerated according to the the available installed
> plug-ins. When no suitable plug-ins are present this
> option will not have any effect. The default is yes.
>
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> ON
> 6.5. ARC review type: Automatic
> 6.6. ARC Exposure: open
>
>
