Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, Oct 28, 2011 at 4:10 AM, Martin Paljak mar...@martinpaljak.net wrote: Now, the fact that there are both binary blob drivers that speak PKCS#11 but also open source drivers (also free, in the sense of free software vs open source software) is as good excuse to reject PKCS#11 as ruling out HTTP from a browser because there might be web servers that are not free software and are run and owned by evil people and insisting on using HTTP-FREE which is incompatible with HTTP. Keep in mind that we are talking about *interfaces* not what's behind it. I might be wrong but I guess that most people run GnuPG on top of motherboards and CPU-s that are far from being free in any sense (firmwares, CPU microcode and designs etc). Where do you draw the border? Just to re-assure you, I'm a huge fan and proponent of both FOSS (and plain OSS) but I also strongly believe in common sense. And common sense tells that using PKCS#11 is a better option than not using it at all or inventing a 15th standard [1]. Another shameless plug here, but the IBM 4765 does have GPL'd firmware, device drivers and open-source (CPL'd) PKCS#11 on top of it. There is a still a binary blob that sits between PKCS#11 and the device driver if you want to use encrypted keys. There's also the TPM, who's stack is completely open-source from PKCS#11 down through the device driver. I'm not aware of a TPM vendor with open source firmware though. Kent IBM LTC Security ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On 10/28/11 4:57 , Werner Koch wrote: On Fri, 28 Oct 2011 11:10, mar...@martinpaljak.net said: PKCS#11 but also open source drivers (also free, in the sense of free software vs open source software) is as good excuse to reject PKCS#11 In 99% percent of all cases Open Source and Free Software describe software distributed under the same terms. Thus it is not helpful to distinguish between them. I had the impression that the distinction between FOSS and plain OSS (and other even less-free options) was important, or the hypothetical possibility of a misguided(?) user choosing a non-free or proprietary PKCS#11 module over a free one would not be that important for GnuPG? Recall that not too long ago pkcs#11 was an interface consisting of some basic core functions with a lot of required proprietary extensions and many of them even shared the same function pointer slot. Sorry, I might be too young for that. Yes, PKCS#11 is far from superior (as a spec) and there are bad implementations and proprietary extensions and whatnot. But a *lot* can be achieved with it (2.11+). Especially on free Unices (which are not major players). Today, not 10 years ago. Meanwhile major players don't use it anymore for interop purposes but defined their own high level standard - similar to what GnuPG did. For smart cards? You mean Minidriver(/CryptoAPI) in Microsoft world and the now extinct Tokend(/CDSA) in OS X world? Why would somebody think that Microsoft or Apple care about interop on *their* (proprietary) platforms, with competing platforms? With all due respect, I don't think that GnuPG is on par with Apple or Microsoft in this matter. Especially for Linux (GNU/BSD etc) the closest thing to an independent third party standard that many could agree upon (in the spirit of GNOME vs KDE problems) in this field is PKCS#11. Suggesting to use SCD instead of PKCS#11 is not realistic, it does not bring us any closer to re-usable cryptographic hardware (be it smart cards or HSM-s you can swap behind EJBCA) Best, Martin -- @MartinPaljak +3725156495 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, Oct 28, 2011 at 12:10:46PM +0300, Martin Paljak wrote: Taking into account the original request of getting something off-the-shelf for PGP uses, this demand basically just rules out GnuPG for some users and use cases. GnuPG, sure - however: [..] the hardware usually comes off-the-shelf only with existing drivers for CryptoAPI, JCE, PKCS#11 [..] JCE is of note, since there are OpenPGP java implementations. This may well not be directly relevant for Thor's intentions and environment, but it's worth pointing out that the range of options is not *quite* as dire and limited as it might seem. -- Dan. pgpIwkowPfrRG.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On 29/10/11 10:09 AM, coderman wrote: On Wed, Oct 26, 2011 at 11:12 AM, Thor Lancelot Simont...@panix.com wrote: I find myself needing a crypto card, preferably PCIe, with onboard key storage ... i too would like to know what other options are available for HSM + Accel in PCIe form factor. Is there any particular reason why PCI(e) is preferred as a hardware interface? iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Sat, Oct 29, 2011 at 08:10:38PM +1100, ianG wrote: Is there any particular reason why PCI(e) is preferred as a hardware interface? Because that's the only thing server boards typically have. Plus, PCIe is much preferable to PCI in terms of throughput (not that makes a bottleneck for a crypto accelerator) and latency. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Wed, Oct 26, 2011 at 7:12 PM, Thor Lancelot Simon t...@panix.com wrote: I find myself needing a crypto card, preferably PCIe, with onboard key storage. The application is PGP, so I really need hardware that can use keys stored onboard to do arbitrary RSA operations -- rather than a protocol accellerator which can use onboard keys only to do more complex operations that happen to include RSA signing or encryption as one step. As far as I know, the only current products that do this are the IBM 4765 and the BCM586x line of chips. There were more sources once-upon-a-time of course -- nCipher and NetOctave/NBMK/etc. but those products seem to be gone now (and have obsolete PCI host interfaces, as well). ? http://www.thales-esecurity.com/en/Products/Hardware%20Security%20Modules/nShield%20Solo.aspxfor example. I cannot actually find a card with a BCM586x on it, and there is a suspicious absence of pricing and availability information on those parts from the usual IC distributors' web sites as well. What, if anything, can I buy off-the-shelf in this space? I don't think a smartcard will work, since I need unattended operation within the chassis of a standard x86 rackmount server. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, 28 Oct 2011 14:03, t...@panix.com said: So this appears to be basically a smartcard and USB smartcard reader built into the same frob. I can probably find a way to put it within Right. Unfortunately, it also appears to be unbuyable. I tried all three sources listed on the crypto-stick.org website yesterday: two were out of stock, while the third said something along the lines of They are manually assembled thus you won't see much in stock. Your better choice is to buy one of the Zeitcontrol OpenPGP cards and an SCM USB stick style reader [1] - you get exactly the same. Salam-Shalom, Werner [1] Never buy an Omnikey card reader unless you can want to use it only on Windows. Only the Windows drivers allows the use of 2k keys. The omnikey chip supports Extended Length APDUs only via proprietary and undocumented features. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, 28 Oct 2011 11:10, mar...@martinpaljak.net said: PKCS#11 but also open source drivers (also free, in the sense of free software vs open source software) is as good excuse to reject PKCS#11 In 99% percent of all cases Open Source and Free Software describe software distributed under the same terms. Thus it is not helpful to distinguish between them. And common sense tells that using PKCS#11 is a better option than not using it at all or inventing a 15th standard [1]. Well, GnuPG had support for several cards before there was any _working_ pkcs#11 driver for any available card on non-Windows platforms. Recall that not too long ago pkcs#11 was an interface consisting of some basic core functions with a lot of required proprietary extensions and many of them even shared the same function pointer slot. Meanwhile major players don't use it anymore for interop purposes but defined their own high level standard - similar to what GnuPG did. Anyway, we had this discussion on the gnupg lists often enough that it does not make sense to repeat our views here again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Martin Paljak mar...@martinpaljak.net writes: Taking into account the original request of getting something off-the-shelf for PGP uses, this demand basically just rules out GnuPG for some users and use cases. At the risk of slight self-promotion, cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/, has supported PKCS #11 for PGP use since pretty much forever. It's a crypto toolkit rather than a complete app like GPG, but it's there if you want it. So far no part of me has turned green and fallen off just because I used a closed-source PKCS #11 driver. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Thor Lancelot Simon wrote: On Thu, Oct 27, 2011 at 12:15:32PM +0300, Martin Paljak wrote: You have not described your requirements (ops/sec, FIPS/CC etc) but if the volume is low, you could take USB CryptoStick(s) (crypto-stick.org), which is supported by GnuPG and what can do up to 4096 bit onboard keys, unfortunately only one signature/decryption pair usable through GnuPG. Probably you can also stack them up and populate with the same key for load sharing. So this appears to be basically a smartcard and USB smartcard reader built into the same frob. I can probably find a way to put it within the chassis of even a fairly compact rackmount server without fear it will come loose and take the application offline. Unfortunately, it also appears to be unbuyable. I tried all three sources listed on the crypto-stick.org website yesterday: two were out of stock, while the third said something along the lines of low stock - order soon, walked me through the whole ordering process, then said my order had been submitted -- without ever asking for payment. It's possible I might walk into my office next week and see two crypto-sticks, provided free of charge, but I am not too optimistic about that! Is there a way to actually get these? This sounds familiar to me: while the direct cost, per unit, of crypto gear would seem very low when compared with mass market devices with the same kind of electronics, crypto gear remains very difficult to procure without a massive contribution to engineering costs incurred by the supplier (for the crypto added value). Ultimately a crypto gear under discussion is merely a CPU plus a rudimentary memory subsystem and an interface to a host (it may have a separate keypad, and/or a key injection port). The packaging matters to provide confidence that the secret/private keys remain onboard. Likewise, the API with the host is a can of worm about which you want to avoid discussion, again to provide this well informed sense of assurance that information risks and controls are in balance. This being said, there is indeed a practical security benefit of having computations directly involving secret/private keys done by a CPU unlikely to be infected by a Trojan. Security certification concerns put aside, the architectural demands are no more elaborate than a CPU unlikely to be infected by a Trojan. From there, you either pay for the certification gimmick, or you mend your own solution. This is the basis for an open source HSM ... Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Take a cheap Android, write the code you need for it, make it talk via USB, rip out all antennas, put it in your box (wrap in a paper bag first), and connect with USB cable to the internal USB port. HW cost: $80 a Trojan. Security certification concerns put aside, the architectural demands are no more elaborate than a CPU unlikely to be infected by a Trojan. From there, you either pay for the certification gimmick, or you mend your own solution. This is the basis for an open source HSM ... cryptography mailing list ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Or pluk any old PC/laptop/notebook you have lying around and make it talk over IP. Phones consume less energy though, nice idea. It's arguably more secure than a CPU but I doubt it'd make a noticeable difference (since the rest of the hardware needs to be secure also). 2011/10/28 Morlock Elloi morlockel...@yahoo.com: Take a cheap Android, write the code you need for it, make it talk via USB, rip out all antennas, put it in your box (wrap in a paper bag first), and connect with USB cable to the internal USB port. HW cost: $80 a Trojan. Security certification concerns put aside, the architectural demands are no more elaborate than a CPU unlikely to be infected by a Trojan. From there, you either pay for the certification gimmick, or you mend your own solution. This is the basis for an open source HSM ... cryptography mailing list ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Wed, Oct 26, 2011 at 11:12 AM, Thor Lancelot Simon t...@panix.com wrote: I find myself needing a crypto card, preferably PCIe, with onboard key storage As far as I know, the only current products that do this are the IBM 4765 and the BCM586x line of chips. There were more sources once-upon-a-time of course -- nCipher and NetOctave/NBMK/etc. but those products seem to be gone now (and have obsolete PCI host interfaces, as well). i've used Sun Cryptographic Accelerator 6000s with success. however, as of some months ago Oracle changed their retail price from $1,499 to $9,999. you can still find second hand for a grand or so. expect to jump through hoops to get drivers, firmware, etc. (contact me off list if needed) i too would like to know what other options are available for HSM + Accel in PCIe form factor. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Wed, Oct 26, 2011 at 8:12 PM, Thor Lancelot Simon t...@panix.com wrote: I find myself needing a crypto card, preferably PCIe, with onboard key storage. The application is PGP, so I really need hardware that can use keys stored onboard to do arbitrary RSA operations -- rather than a protocol accellerator which can use onboard keys only to do more complex operations that happen to include RSA signing or encryption as one step. As far as I know, the only current products that do this are the IBM 4765 and the BCM586x line of chips. There were more sources once-upon-a-time of course -- nCipher and NetOctave/NBMK/etc. but those products seem to be gone now (and have obsolete PCI host interfaces, as well). I cannot actually find a card with a BCM586x on it, and there is a suspicious absence of pricing and availability information on those parts from the usual IC distributors' web sites as well. What, if anything, can I buy off-the-shelf in this space? I don't think a smartcard will work, since I need unattended operation within the chassis of a standard x86 rackmount server. Thor Hi Thor, For a past project, I've been engineering a cryptographic appliance running with Bull TrustWay CC2000 http://support.bull.com/ols/product/security/trustway/c2000/cc2000.html It is a full-length PCI with on-board key storage. Cheers, -- alfonso blogs at http://Plaintext.crypto.lo.gy tweets @secYOUre ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Alfonso De Gregorio a...@crypto.lo.gy writes: For a past project, I've been engineering a cryptographic appliance running with Bull TrustWay CC2000 http://support.bull.com/ols/product/security/trustway/c2000/cc2000.html It is a full-length PCI with on-board key storage. Can you provide a bit more information on this thing? Your post actually contains at least as much data on it as Bull's web page. From the little info that's available, it's just another PCI crypto card, and if it's from Bull it's probably going to cost an arm and a leg. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Thor Lancelot Simon schrieb: As far as I know, the only current products that do this are the IBM 4765 and the BCM586x line of chips. There were more sources once-upon-a-time of course -- nCipher and NetOctave/NBMK/etc. but those products seem to be gone now (and have obsolete PCI host interfaces, as well). Don't know about other current products, but nCiphers nShield are available with PCIe and function as universal HSM, not just as protocol accelerator. Juergen ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Thu, 27 Oct 2011 11:15, mar...@martinpaljak.net said: I don't know about PGP(.com), but GnuPG is picky about hardware key containers. Things like PKCS#11. For the records: That is simply not true. We only demand an open API specification for the HSM because we don't want to support binary blob pkcs#11 drivers. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Hi Peter, On Thu, Oct 27, 2011 at 10:45 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Alfonso De Gregorio a...@crypto.lo.gy writes: For a past project, I've been engineering a cryptographic appliance running with Bull TrustWay CC2000 http://support.bull.com/ols/product/security/trustway/c2000/cc2000.html It is a full-length PCI with on-board key storage. Can you provide a bit more information on this thing? Your post actually contains at least as much data on it as Bull's web page. From the little info that's available, it's just another PCI crypto card, and if it's from Bull it's probably going to cost an arm and a leg. Peter. Absolutely. The documentation was always rather scarce. I first heard about that card talking with the Trustway head of unit, when we were both in Brussels serving the European Commission as evaluators of some research projects. The appliances I was involved in were SSCDs (Secure Signature Creation Device) designed in the context of EU Directive for Electronic Signatures. The cryptographic card by Bull Evidian is designed according to two protection profiles relevant for this application scenario, the CEN CWA 14167-2 and CEN CWA 14167-3, and certified CC EAL4 -- online there is the security target of a new revision of the same card http://www.ssi.gouv.fr/IMG/certificat/ANSSI-CC-cible_2010-10en.pdf The CC2000 was provided with a Linux device driver and a PKCS#11 engine for OpenSSL. If the project was to be supported by my personal financial resources I would ended up injuring both an arm and a leg... But in the end I managed to negotiate contract terms well suited with the requirements/constraints of a small enterprise, saving my arms! Cheers, -- alfonso blogs at http://Plaintext.crypto.lo.gy tweets @secYOUre ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
