User Tools

Site Tools

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at <<<<<<<<<<


This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doc:hardware:cryptographic.hardware.accelerators [2013/03/25 21:15]
doc:hardware:cryptographic.hardware.accelerators [2016/05/17 04:24] (current)
JW0914 [Historical]
Line 1: Line 1:
 +====== Cryptographic Hardware Accelerators ======
 +A Cryptographic Hardware Accelerator can be 
 +  * integrated into the [[doc:​hardware:​SoC]] as a separate processor, as special purpose CPU (aka Core).
 +  * integrated in a [[wp>​Coprocessor]] on the circuit board
 +  * contained on a Chip on an extension circuit board, this can be connected to the mainboard via some BUS, e.g. PCI
 +  * an [[wp>​Template:​Multimedia_extensions|ISA extension]] like e.g. [[wp>AES instruction set]] and thus integral part of the CPU (in that case a kernel driver in not needed)
 +The purpose is to load off the very computing intensive tasks of encryption/​decryption and compression/​decompression.\\
 +As can be seen in this [[wp>AES instruction set]] article, the acceleration is usually achieved by doing certain arithmetic calculation in hardware.
 +When the acceleration is not in the instruction set of the CPU, it is supported via a kernel driver (/​dev/​crypto).
 +There are two drivers offering /dev/crypto in OpenWRT:
 +  * [[https://​​openwrt/​packages/​tree/​master/​utils/​cryptodev-linux|Cryptodev-linux]] kernel module, which utilizes the Linux kernel crypto drivers
 +  * OCF (OpenBSD Crypto Framework), which utilizes the OpenBSD crypto drivers
 +Both ways result to a /dev/crypto device which can be used by userspace crypto applications (e.g., the ones that utilize openssl or gnutls).
 +===== Performance =====
 +Depending on which arithmetic calculations exactly are being done in the specific hardware, the results differ widely. You should not concern yourself with theoretical bla,bla but find out how a certain implementation performs in the task you want to do with it! You could want to
 +  * you could attach a USB drive to your device and mount a [[doc/​howto/​|local filesystem]] like ext3 from it. Then you want to read from and write to this filesystem from the Internet over a secured protocol. Let's use ''​sshfs''​. You would set up a  [[doc:​howto:​sshfs.server]] on your device and a [[doc:​howto:​sshfs.client]] on the other end. Now how fast can you read/write to this with and without Cryptographic Hardware Accelerators. If the other end, the client, is a "fully grown PC" with a 2GHz CPU, it will probably perform fast enough to use the entire bandwidth of your Internet connection. If the server side is some embedded device, with let's say some 400MHz MIPS CPU, it could benefit highly from some integrated (and supported!) acceleration. You probably want enough performance,​ that you can use your entire bandwidth. Well, now go and find some benchmark showing you precisely the difference with enabled/​disabled acceleration. Because you will not be able to extrapolate this information from specifications you find on this page or on the web.
 +  * you could want to run an OpenVPN or an OpenConnect server on your router/​embedded device, instead of using WEP/​WPA/​WPA2. There will be no reading from/​writing to a USB device. Find benchmarks that show you exactly the performance for this purpose. You won't be able to extrapolate this information from other benchmarks.
 +  * think of other practical uses, and find specific benchmarks.
 +===== Enabling /dev/crypto =====
 +Run ''​make menuconfig''​ and select
 +==== With cryptodev-linux ====
 +  * kmod-crypto-core:​ m
 +    * kmod-cryptodev:​ m
 +==== With OCF ====
 +This must not be combined with cryptodev-linux.
 +Kernel modules -> Cryptographic API modules
 +  * kmod-crypto-core:​ m
 +    * kmod-crypto-ocf:​ m
 +  * ocf-crypto-headers:​ m
 +===== Adding /dev/crypto support to crypto libraries =====
 +Libraries -> SSL
 +  * libopenssl: m
 +    * Crypto acceleration support: y
 +  * libgnutls: m
 +    * enable /dev/crypto support: y
 +Note that there are some known issues with [[http://​​Ticket/​Display.html?​id=2770&​user=guest&​pass=guest|openssl'​s /dev/crypto support]].
 +===== Enabling specific hardware driver =====
 +==== Soekris vpn1411 ====
 +  * [[http://​​vpn1401.htm]]
 +Run ''​make menuconfig''​ and select
 +Kernel modules -> Cryptographic API modules
 +  * kmod-crypto-core:​ m
 +    * kmod-crypto-aes:​ m
 +    * kmod-crypto-des:​ m
 +    * kmod-crypto-hw-hifn-795x:​ m
 +==== Marvell CESA ====
 +Cryptographic Engine and Security Acceleration ​
 +  * [[http://​​search?​sclient=psy&​hl=en&​source=hp&​​btnG=Search|PDF download]]
 +  * [[toh/​seagate/​dockstar#​crypto.hardware.acceleration|Seagate Dockstar]]
 +  * 2.6.32: AES [[http://​​p=linux/​kernel/​git/​torvalds/​linux-2.6.git;​a=commitdiff;​h=85a7f0ac5370901916a21935e1fafbe397b70f80|commit]]
 +  * 2.6.35: SHA1 and HMAC-SHA1 [[http://​​p=linux/​kernel/​git/​torvalds/​linux-2.6.git;​a=commitdiff;​h=750052dd2400cd09e0864d75b63c2c0bf605056f|commit]]
 +  * [[https://​​changeset/​22877|r22877]]:​ [kirkwood] Add kernel package for the mv_cesa crypto module
 +  * [[https://​​changeset/​23145|r23145]]:​ [kirkwood] Fix mv_cesa module dependencies and .ko file location Thanks KanjiMonster & Memphiz
 +  * [[https://​​changeset/​23229|r23229]]:​ [packages/​kernel] Make mv_cesa crypto module available on Orion as well.
 +  * [[https://​​changeset/​23383|r23383]]:​ [package] kernel: underscores in package names are bad, rename kmod-crypto-mv_cesa to kmod-crypto-mv-cesa
 +  * [[https://​​changeset/​26406|r26406]]:​ kernel: add a missing dependency for the mv_cesa crypto driver
 +  * [[https://​​changeset/​26407|r26407]]:​ kernel: mv_cesa depends on CRYPTO_BLKCIPHER2 and CRYPTO_HASH2
 +  * [[https://​​changeset/​26413|r26413]]:​ kernel: remove double definition of depends in crypto-mv-cesa and make it look like the other entries. Thank you Maarten
 +==== Geode AES engine ====
 +  * [[toh/​pcengines/​alix#​using.the.geode.s.aes.engine]]
 +==== VIA padlock ====
 +  * [[http://​​en/​initiatives/​padlock/​hardware.jsp|VIA Padlock security engine]]
 +  * [[wp>​Padlock_(disambiguation)]]
 +  * http://​​blog/?​p=198
 +==== Historical ​ ====
 +<​sup>​**Note:​** If you want to learn about the current situation, you should search the Internet or maybe ask in the forum. This is outdated. Especially if you want to know, how fast a copy from a mounted filesystem (say ext3 over USB) over the scp is, you should specifically search for such benchmarks.</​sup>​
 +<​sup>​Some models of the BCM47xx/​53xx family support hardware accelerated encryption for IPSec (AES, DES, 3DES), simple hash calculations (MD5, SHA1) and TLS/​SSL+HMAC processing. Not all devices have a hw crypto supporting chip. At least Asus WL500GD/X, Netgear WGT634U and Asus WL700gE do have hw crypto. ​ However, testing of a WGT634U indicates that a pin under the BCM5365 was not pulled low to enable strong bulk cryptography,​ limiting the functionality to single DES.</​sup>​
 +  * <​sup>​How did you find that out?</​sup>​
 +    * <​sup>​Do you get an interrupt when sending a crypto job to the chip and limiting the request to DES only?​)</​sup>​
 +<​sup>​The specification states the hardware is able to support 75Mbps (9,4MB/s) of encrypted throughput. Without hardware acceleration using the blowfish encryption throughput is only ~0,​4MB/​s.</​sup>​
 +<​sup>​Benchmark results that show the difference between software and hardware accelerated encryption/​decryption can be found [[http://​​files/​src/​bcm5365p/​bench/​|here]]. Due to the overhead of hardware/​DMA transfers and buffer copies between kernel/user space it gives only a good return for packet sizes greater than 256 bytes. This size can be reduced for IPSec, because network hardware uses DMA and there is no need to copy the (encrypted) data between kernel and user space.</​sup>​
 +<​sup>​The hardware specification needed for programming the crypto API of the bcm5365P (Broadcom 5365P) can be found [[http://​​bcm5365p.pdf|here]].</​sup>​
 +  * <​sup>​The crypto chip is accessible through the SSB bus (Sonics Silicon Backplane). A Linux driver for SSB is available in OpenWRT'​s kernel >= 2.6.23 (Kamikaze)</​sup>​
 +  * <​sup>​An example about how to communicate with the crypto chip can be found [[http://​​files/​src/​bcm5365p/​|here]] (file b5365ips.tar.bz2).</​sup>​
 +  * <​sup>​An OCF Linux driver that works with the ASUS WL500gP can be found in Trunk (SVN) or [[http://​​files/​src/​bcm5365p/​|here]] and is called **ubsec_ssb**. Only OCF-enabled applications can be accelerated. That means, if you want e.g. an accelerated OpenSSH you have to manually enable cryptodev in OpenSSL. The driver is still considered experimental.</​sup>​
 +  * <​sup>​Links to mailing-list posts with references to more recent and working version of Linux driver for Broadcom crypto chips [[http://​​l=openssl-dev&​m=110915540208913&​w=2|here]] and [[http://​​​msg18804.html|here]].</​sup>​
 +  * <​sup>​Sun Crypto Accelerator 500 and 1000 (X6762A) cards are based on BCM5821. Might be worth checking Solaris references as well. [[http://​​source/​xref/​crypto/​quantis/​usr/​src/​uts/​common/​crypto/​io/​|Here]] is OpenSolaris driver for Broadcom crypto chips.</​sup>​
 +  * <​sup>​Asus WL-700gE sources come with patched FreeSwan to utilize ubsec.</​sup>​
 +  * <​sup>​Closed-source binary included in Asus Wl-700gE sources do support AES based on headers.</​sup>​
 +  * <​sup>​There'​s a [[http://​​|Linux port]] of the OpenBSD Cryptographic Framework (OCF) but the ubsec driver (Broadcom 58xx PCI cards) is not ported yet. If you compile OCF with the /dev/crypto device driver, userspace applications and libraries such as OpenSSL can be accelerated. There are patches for Openswan as well.</​sup>​
 +  * <​sup>​[[http://​​viewtopic.php?​id=5032|Discussion]] about hardware accelerated crypto.</​sup>​
 +  * <​sup>​Various versions of old [[http://​​openwrt/​bcm5820/​|BCM5820 driver sources]].</​sup>​
 +  * <​sup>​BCM5801/​BCM5805/​BCM5820 Security Processor Software Reference Library http://​​products/​access_request.php?​category_id=0&​id=7&​filename=5801-5805-5820-SRL101-R.pdf</​sup>​
 +  * <​sup>​Cisco PIX VAC+ Encryption module is 64-bit PCI card based on Broadcom BCM5823. Another similar card is Checkpoint VPN-1 Accelerator Card II, III and IV from [[http://​​|Silicom]].</​sup>​
 +<​sup>​| ​ SoC / CPU  |  Accelerated Methods ​ |  Datasheet ​ |</​sup> ​
 +<​sup>​| ​ BCM94704AGR ​ |  WEP 128, AES OCB AES CCM  |  [[http://​​collateral/​pb/​94704AGR-PB00-R.pdf|94704AGR-PB00-R.pdf]] ​ |</​sup> ​
 +<​sup>​| ​ BCM?​4704P ​ |  WEP 128, AES OCB, AES CCM, VPN  |  [[http://​​collateral/​pb/​94704AGR-PB00-R.pdf|94704AGR-PB00-R.pdf]] ​ |</​sup> ​
 +<​sup>​| BCM5365 ​ |  AES (up to 256-bit CTR and CBC modes), DES, 3DES (CBC), HMAC-SHA1, HMAC-MD5, SHA1 and MD5. IPSec encryption and single pass authentication. ​ |  [[http://​​collateral/​pb/​5365_5365P-PB01-R.pdf|5365_5365P-PB01-R.pdf]] ​ |</​sup> ​
 +<​sup>​| BCM5365P ​ |  AES (up to 256-bit CTR and CBC modes), DES, 3DES (CBC), HMAC-SHA1, HMAC-MD5, SHA1 and MD5. IPSec encryption and single pass authentication. ​ |  [[http://​​collateral/​pb/​5365_5365P-PB01-R.pdf|5365_5365P-PB01-R.pdf]] ​ |</​sup> ​
 +===== Tags =====