Re: [opensc-devel] usb p11 token
Frank Morgner wrote: > > > But you can also accept the overhead and use standardized > > > interfaces. This approach gives you support for a wide variety of > > > applications and (existent) hardware/software. > > > > The *only* interface that matters is p11. > > This is not true in many regards. But if all you focus on is p11 > then I can understand you. Let me assure that it is not by choice. I fiercely resisted p11 for a long time. I think the API reaks of DOS. But it is the only thing that the world is using for crypto tokens, so it is the only thing that matters. > the age is your argument? The layers of crap on top of layers of crap is my argument. There is no reason to deal with T=0 or T=1 when there is USB. Yet someone thought it was a good idea to make USB emulate a much more cumbersome protocol. //Peter pgpCnKAGulm4Q.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On Tuesday, April 26 at 09:07PM, Peter Stuge wrote: > Frank Morgner wrote: > > But you can also accept the overhead and use standardized > > interfaces. This approach gives you support for a wide variety of > > applications and (existent) hardware/software. > > The *only* interface that matters is p11. This is not true in many regards. But if all you focus on is p11 then I can understand you. > All the other crap is 30 year old legacy that the world would be > better without, sooner rather than later! > > Thus it makes sense to implement p11 directly on top of a modern > transport. So the age is your argument? Wikipedia says that PKCS was created 1991, 4 years before 7816-4 was released. Anyway, no need to go deeper into this. If you need nothing more than to transfer bytes conforming to p11, you might as well avoid overhead caused by everything else. BTW, neither the CCID-emulator nor the virtual smartcard mentioned earlier [1] are forcing you to use APDUs and allowing you to exchange buffers of any kind (at least if #237 [2] was realised). Cheers, Frank. [1] http://www.opensc-project.org/pipermail/opensc-devel/2011-April/016504.html [2] http://www.opensc-project.org/opensc/ticket/237 pgp29XBnCE2bg.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 26/04/2011 19:16, Anders Rundgren wrote: > As far as I know not a single HSM (even those who cost $20 000) > out there is able to certify that keys actually were created > inside of the HSM!!! A $10-$20 SKS always attests the origin > of created keys using a built-in device key and certificate. Then you have to trust that certificate, trust that it's been installed securely, trust who issued it... Quite a lot of things you can't control, don't you think? What about a "virgin" device that the first time you turn it on generates a new key and only accepts "set params", "generate new key", "get self-signed cert" and "store this cert" until *you* store a cert? You can do it on an offline PC, booted from a CD. You have full control. Fear TEMPEST attacks? Just use a jammer and do some random data transfer to other USB devices... If the device doesn't accept "store key" command, then all keys it uses must have been generated locally :) > With a planned addition to KeyGen2 you will be able to put > certificates in devices (servers, routers, etc) using a > SCEP-like process that (due to the device certificate) can > be performed [securely] without an enrollment password. I still miss the sense of SCEP. Must study it... But I fear it just shifts security perimeter to another entity. > SKS is a "simple smartcard". That it looks complex is because > provisioning is really 10 times as complex as performing an > "RSA Sign". IIUC, just because "you" are using the wrong security perimeter at the wrong time. *If* you can *securely* load a single cert on the HSM, then all is easy (even easier than RSA, if you want). If you can't, *nothing* can be trusted. If, at initialization, you store a second certificate for administrator (even if I'd prefer weights for a Tree Parity Machine to be used as a shared symmetric key generator, to have perfect forward secrecy even in case of compromise), you're OK and can administer securely the HSM from anywhere. And since you're working inside a trusted perimeter, you don't need convoluted protocols that only delegate security to another party. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 26/04/2011 15:19, Alon Bar-Lev wrote: > Just wanted to note that exposing such device to IP stack makes it a > target to hack, That's why I'm quite reluctant to enable Ethernet port on such a dongle. > packaging is much more difficult. I don't want to compete with $20k HSM. They use dedicated HW for good reasons. I only want something I can plug in my servers at work to be sure that no *remote* intruder can compromise my keys and make me revoke all certs (can be quite costy!). > Also, that in crypto caching is not a problem as 99.99% of time > the content of the crypto device is constant. Unless you keep some state vars on the device (ugly). But when it changes (new key/cert added, PIN changed, etc), that change must be propagated atomically to all clients. > About using USB directly, well, I disagree... I see this much like GPS > device, with a simple optional multiplexer for applications (local and > remote). When you use libusb, you claim() a device to get exclusive access. Then you handle it as you like. Usually a daemon claims the device and listens for socket/pipe connections actually multiplexing access and abstracting low-level protocol. > Implementation of hardware independent stream protocol will allow > using crypto in many scenarios (serial, USB, unix sockets, tcp, ssh) > with the PKCS#11 forwarding features built-in. You need "something" to forward it (unless I missed an SSH option "forward this serial port"), be it serial, USB or socket. And once you have a running daemon (pcscd, maybe?) that accepts socket/pipe connections from localhost, you're OK. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Frank Morgner wrote: > But you can also accept the overhead and use standardized > interfaces. This approach gives you support for a wide variety of > applications and (existent) hardware/software. The *only* interface that matters is p11. All the other crap is 30 year old legacy that the world would be better without, sooner rather than later! Thus it makes sense to implement p11 directly on top of a modern transport. //Peter pgpWi88z9yPHf.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On Tuesday, April 26 at 08:34PM, NdK wrote: > > On 26/04/2011 18:51, Frank Morgner wrote: > > > You forgot to mention Virtual Smart Card Architecture > Already seen that, but always "wrappers wrapped in other wrappers" :( Well, it IS what you requested: CCID+virtual token. > The architecture can be greatly simplified: no need for APDUs > encoding/decoding, no need to handle card insertion/extraction, no > need to know if it's T=0 or T=1 ... Direct leveraging of USB should > allow a really light interface. Sure, you can do some hacking on your computer to support a device that you designed yourself to fit your use case. But you can also accept the overhead and use standardized interfaces. This approach gives you support for a wide variety of applications and (existent) hardware/software. Cheers, Frank. pgpYaVQ10y63V.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 26/04/2011 18:51, Frank Morgner wrote: > You forgot to mention Virtual Smart Card Architecture Already seen that, but always "wrappers wrapped in other wrappers" :( The architecture can be greatly simplified: no need for APDUs encoding/decoding, no need to handle card insertion/extraction, no need to know if it's T=0 or T=1 ... Direct leveraging of USB should allow a really light interface. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 2011-04-26 14:55, NdK wrote: > Il 26/04/2011 12:41, Anders Rundgren ha scritto: >> An unusual (unique?) aspect of the mentioned project is that >> it is designed to be integrated in browsers. > It aims at "client" security. My target is server security, so I don't > have to leave .key files around. In case of server compromission, I only > have to reinstall it, w/o having to revoke its certs. > Actually, sort-of TPM module (I could even use TPM, but it's only > available on some motherboards :( and I don't know how fast it can be). It is true that the primary focus is on clients. However, the architecture is by no means limited to clients. As far as I know not a single HSM (even those who cost $20 000) out there is able to certify that keys actually were created inside of the HSM!!! A $10-$20 SKS always attests the origin of created keys using a built-in device key and certificate. With a planned addition to KeyGen2 you will be able to put certificates in devices (servers, routers, etc) using a SCEP-like process that (due to the device certificate) can be performed [securely] without an enrollment password. > >> Although maybe not exactly what you guys are looking for, the >> prime target for the project are people who are NOT interested >> in security or at least know very little about it! Since they >> represent 99% of all users it looks a bigger market :-) > They're not interested as long as theyr money isn't affected. If their > money gets affected, then they become really interested :) > My project is surely heavily overkill for a client. Just like a simple > smartcard is not enough to handle SSL hanshakes on a (moderately to > heavily) busy https server. SKS is a "simple smartcard". That it looks complex is because provisioning is really 10 times as complex as performing an "RSA Sign". Cheers, Anders > BYtE, > Diego. > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On Tuesday, April 26 at 12:41PM, Anders Rundgren wrote: > > I don't know what you had in mind with an "USB P11 token" > but in case you would like to participate in an effort > making sort of a USB P11 token there is already a project > to dig in to: > > http://webpki.org/auth-token-4-the-cloud.html You forgot to mention Virtual Smart Card Architecture http://sourceforge.net/projects/vsmartcard/ ;-) It includes a virtual smartcard (Python) with some SM and a CCID-Emulator. The latter works with Linux only, but it is possible to literally plug into an computer as a smartcard reader. I used virtual smartcard and reader to use my mobile phone (OpenMoko) as authentication token on an other PC via USB, more smartcard use cases are possible! Cheers, Frank. pgpbqEzfcvTSI.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Just wanted to note that exposing such device to IP stack makes it a target to hack, packaging is much more difficult. Also, that in crypto caching is not a problem as 99.99% of time the content of the crypto device is constant. About using USB directly, well, I disagree... I see this much like GPS device, with a simple optional multiplexer for applications (local and remote). We discussed PKCS#11 forwarding some time ago [1] and some time before. Implementation of hardware independent stream protocol will allow using crypto in many scenarios (serial, USB, unix sockets, tcp, ssh) with the PKCS#11 forwarding features built-in. Just a though... but any implementation will do. [1] http://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg01733.html On Tue, Apr 26, 2011 at 3:44 PM, NdK wrote: > Il 26/04/2011 11:28, Alon Bar-Lev ha scritto: > >>> Since speed is quite critical, I was thinking to use something like G20 >>> Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it >>> can be WAY cheaper than other solutions), but it's tiny, fast (400MHz >>> ARM9), can work as USB device (and host, maybe to keep a master key on a >>> standard smart card used only once at boot time), can accomodate a >>> (small) display and many keys, and there's a module with an FPGA if you >>> want/need to implement some crypto acceleration in HW. >>> There's even an Ethernet port (better not to use it... :) ). Too bad USB >>> runs at most at 12Mbps, but that shouldn't be an issue. >> There is no reference for this board in the link you sent. > Ops! Sorry: http://acmesystems.it ! Translated first level domain too :( > >> It would be a great solution if the device will be very small and run Linux! >> It would be lovely to have PIN keypad and BIO reader on board as-well. > There are a lot of IO lines available. Just don't count too much on > serial (UART) interfaces: known to have some speed problems (should be > fixed soon, BTW). > >> However, I want to raise some issues. >> Developing an implementation that directly accesses the USB device >> impose fundamental security issue. As it requires the user to have >> special privilege. It is true that on modern linux, udev can deal with >> some device privilege settings, but it would be better to emulate some >> standard interface, such as serial over USB. > Possible, but I'm sure we can come to something better :) Encapsulating > too many protocols one inside the other always gives troubles. > > [...] >> Then you need to deal with device sharing. Stateless implementation >> (connect, operate, disconnect) would solve this, while creating some >> authentication cookie with the device. > I'm usually not for stateless implementations for stateful devices. To > avoid DoS attacks, state can be kept (for a reasonable time) by client, > in encrypted form. > >> And need to deal with channel encryption secured messaging is not >> this strong... > Since it's a completely new device with its own protocol, it's even > possible to do something like: > - get device's cert (or public key) together with an encrypted nonce > - send it your cert (or public key) and another nonce > - get first nonce's decryption key, encrypted under your public key and > signed by device > - setup session key as an hash of the two nonces > - use this session key for the rest of the session > > But maybe it's "a bit" overkill: USB is "enough" point-to point (much > more than standard card interface, that could be "received" from a > certain distance by its interferences...). > >> And last, power management should be applied, so device will be able >> to be powered down while inactive. This should be simple if stateless >> mode is used and if authentication cookies are stored in non-volatile >> memory. > That's one of the last problems... It consumes so little (and aims a > target where power saving is not really a priority) that you can simply > use internal powersaving. Even if it gets detached, it's like if you > detach a smart card while in use. > >> After solving the above, it is all about PKCS#11 API serialization. >> Most of the PKCS#11 objects may be loaded into the host computer. Only >> private key operations should be serialized and sent to device in >> runtime. > Well, since you can have up to *16GB* memory (SDHC) on that device, > storing objects is not a real problem :) > > BYtE, > Diego. > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 12:26, Peter Stuge ha scritto: > NdK wrote: >> Fox Board ( http://acmesystems.com/ ). > .it Good catch :) > I will probably get a gumstix board for another couple of projects, > and might prototype on that. I'm not sure the final system should run > Linux because it's a whole lot of code for a simple device and > because it does require more expensive hardware. The more expensive > boards are great for prototyping though. Well, having Linux is good for software reuse: you need openssl? It's there! Need GPG? Present! :) >> Too bad USB runs at most at 12Mbps, but that shouldn't be an issue. > I don't think that will be a problem, no. I don't think any of these devices can do tenths of RSA-2048 encryptions per second (unless you use the FPGA), so USB shouldn't get saturated :) But this makes me wonder if they can handle enough SSL handshakes for a web server... (probably yes, if keepalive is in effect and there aren't too many concurrent clients). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 12:41, Anders Rundgren ha scritto: > I don't know what you had in mind with an "USB P11 token" > but in case you would like to participate in an effort > making sort of a USB P11 token there is already a project > to dig in to: > http://webpki.org/auth-token-4-the-cloud.html Interesting. Didn't know about it. Seems a bit resource-constrained at a first look, but worth a deeper exam. > Just drop me a line if you are interested. I'm particularly > interested in USB, P11, Mac, Electronics, and Browser competences. Always interested in all what's security-related. > An unusual (unique?) aspect of the mentioned project is that > it is designed to be integrated in browsers. It aims at "client" security. My target is server security, so I don't have to leave .key files around. In case of server compromission, I only have to reinstall it, w/o having to revoke its certs. Actually, sort-of TPM module (I could even use TPM, but it's only available on some motherboards :( and I don't know how fast it can be). > Although maybe not exactly what you guys are looking for, the > prime target for the project are people who are NOT interested > in security or at least know very little about it! Since they > represent 99% of all users it looks a bigger market :-) They're not interested as long as theyr money isn't affected. If their money gets affected, then they become really interested :) My project is surely heavily overkill for a client. Just like a simple smartcard is not enough to handle SSL hanshakes on a (moderately to heavily) busy https server. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 11:28, Alon Bar-Lev ha scritto: >> Since speed is quite critical, I was thinking to use something like G20 >> Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it >> can be WAY cheaper than other solutions), but it's tiny, fast (400MHz >> ARM9), can work as USB device (and host, maybe to keep a master key on a >> standard smart card used only once at boot time), can accomodate a >> (small) display and many keys, and there's a module with an FPGA if you >> want/need to implement some crypto acceleration in HW. >> There's even an Ethernet port (better not to use it... :) ). Too bad USB >> runs at most at 12Mbps, but that shouldn't be an issue. > There is no reference for this board in the link you sent. Ops! Sorry: http://acmesystems.it ! Translated first level domain too :( > It would be a great solution if the device will be very small and run Linux! > It would be lovely to have PIN keypad and BIO reader on board as-well. There are a lot of IO lines available. Just don't count too much on serial (UART) interfaces: known to have some speed problems (should be fixed soon, BTW). > However, I want to raise some issues. > Developing an implementation that directly accesses the USB device > impose fundamental security issue. As it requires the user to have > special privilege. It is true that on modern linux, udev can deal with > some device privilege settings, but it would be better to emulate some > standard interface, such as serial over USB. Possible, but I'm sure we can come to something better :) Encapsulating too many protocols one inside the other always gives troubles. [...] > Then you need to deal with device sharing. Stateless implementation > (connect, operate, disconnect) would solve this, while creating some > authentication cookie with the device. I'm usually not for stateless implementations for stateful devices. To avoid DoS attacks, state can be kept (for a reasonable time) by client, in encrypted form. > And need to deal with channel encryption secured messaging is not > this strong... Since it's a completely new device with its own protocol, it's even possible to do something like: - get device's cert (or public key) together with an encrypted nonce - send it your cert (or public key) and another nonce - get first nonce's decryption key, encrypted under your public key and signed by device - setup session key as an hash of the two nonces - use this session key for the rest of the session But maybe it's "a bit" overkill: USB is "enough" point-to point (much more than standard card interface, that could be "received" from a certain distance by its interferences...). > And last, power management should be applied, so device will be able > to be powered down while inactive. This should be simple if stateless > mode is used and if authentication cookies are stored in non-volatile > memory. That's one of the last problems... It consumes so little (and aims a target where power saving is not really a priority) that you can simply use internal powersaving. Even if it gets detached, it's like if you detach a smart card while in use. > After solving the above, it is all about PKCS#11 API serialization. > Most of the PKCS#11 objects may be loaded into the host computer. Only > private key operations should be serialized and sent to device in > runtime. Well, since you can have up to *16GB* memory (SDHC) on that device, storing objects is not a real problem :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 13:47, Peter Stuge ha scritto: > "forces local communications" makes no sense. If the device is > connected via USB then it will be local regardless of which interface > class it uses. And you can even use UsbIP stack if you want... > Maybe you will argue that it should implement CDC Ethernet and expose > a network protocol over USB, so that the device can be anywhere on > the network. That would be simpler to use the included ethernet interface, then... > It's a bad idea because the standard interfaces do not fit the > purpose of the device. It's *very* difficult for people to get their > head around this - you're not the only one - but vendor specific is > very very useful in USB. It's not a bad thing, it just takes a bit of > detail knowledge about USB to see the benefits. And needs to be very well documented. :) Not like many closed vendor specific protocols that float around... > Networking the device is a new requirement. It could make good sense > to go there later, but I would like to start with something that fits > easily into the existing p11 model. Urgh... well, it could even "serve" many servers via lan, but I too think it's something that can come much later. >> How can two parties can communicate with each other while have >> nothing common? Do you prefer unconditional (information-theoretic) security or "simply" computational security? :) Too bad public-key crypto can only be computationally secure :( >> PGP/SSH like manual key exchange may be used, but it is too complex >> for most users. As I said in another mail, you have to define security perimeters. From when the device is manufactured to the moment you load a certificate on it, you must consider it "secure by definition" and always inside a trusted security perimeter. After a cert is loaded, it can leave the security perimeter for the real world. > I thought you meant encryption between applications and device? Do > you mean user to user? Keep different layers separed. If you mix 'em it becomes a mess. Users see "application" level, not p11 (or whatever) level. > The API can be implemented over USB just as well as over DLL. There's > really not a big difference. So using vendor-specific protocol as a sort of RPC? >> What I have in mind is to pull all objects from the device into main >> computer and implement PKCS#11 locally, while delegating only private >> key operations to the device. >> This way you have much faster implementation, and a very simple >> protocol implementation. > Go for it! It's also an interesting idea. Cache coherency issues pops up everywhere in this scenario :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Alon Bar-Lev wrote: > >> it would be better to emulate some standard interface, such as > >> serial over USB. > > > > Absolutely not. > > I would not dismiss this entirely... Yes, entirely. It is incredibly silly to create a protocol on top of stream emulation on top of a protocol which is *ALREADY* structured and reliable. > >> Serial over USB has the advantage to work on all modern operating > >> systems, including Windows (PKCS#11 only not mini CSP). While > >> implementing all logic within userspace. > > > > The same is true for a vendor specific USB interface .. > I don't think a device that won't work in Windows, or will force > writing kernel level driver is something that is usable. You seem not to know the USB driver situation so well. I wouldn't pick USB without knowing that it's a good fit. Sorry, but this is just FUD. The kernel drivers exist since many years. Microsoft have even released their own variant, included since Vista and freely redistributable for XP. > Also using libusb is much more difficult than using a plain tty. Please try to attend my USB firmware development workshop at your earliest convenience. If you'd like to have a look at the files: http://stuge.se/lpc-p1343_buttons.tar.bz2 USB takes care of *all* the shit that needs to be dealt with by *both* application *and* firmware if using a stream interface. Serial ports were popular in the 80s, it's time to move on. And remember that USB is *NOT* a serial port with power. > I really see a lot of advantages of using the most primitive > channel for communication. You contradict yourself. Implementing a protocol on top of stream emulation on top of USB is two layers more than simply using USB directly. > For example, the exact same protocol may be used over TCP/SSH socket. > Or can be proxied to remote ssh session. While direct usage of libusb > forces local communications. "forces local communications" makes no sense. If the device is connected via USB then it will be local regardless of which interface class it uses. Maybe you will argue that it should implement CDC Ethernet and expose a network protocol over USB, so that the device can be anywhere on the network. > >> Serial over USB has also the potential to be a very secured > >> implementation. > > > > That's BS. No device class is more or less secure than any other. > > The security is derived from the complexity of the implementation. > Adding libusb dependency (on both sides) libusb is not a dependency, it's just damn handy. And of course libusb or not is completely irrelevant for the device firmware. > and more complex code of handling the device allocation, makes the > probability of security issues higher. Sorry, what do you mean by device allocation? > > Or maybe you suggest exposing a PKCS#15 filesystem using MSC? > > I thought about exposing the device using standard interfaces. It's a bad idea because the standard interfaces do not fit the purpose of the device. It's *very* difficult for people to get their head around this - you're not the only one - but vendor specific is very very useful in USB. It's not a bad thing, it just takes a bit of detail knowledge about USB to see the benefits. > Yes, accessing the file system can be done using MSC. > Performing private key operations can be done using serial. Sigh. > However, I do not recommend of using MSC as it won't allow to proxy > the device into a remote location. Networking the device is a new requirement. It could make good sense to go there later, but I would like to start with something that fits easily into the existing p11 model. > > Encrypt away. No problem. > > I did not find a decent solution for this, mind to share your view? > How can two parties can communicate with each other while have > nothing common? > PGP/SSH like manual key exchange may be used, but it is too complex > for most users. I thought you meant encryption between applications and device? Do you mean user to user? > > I basically have PKCS#11 over USB in mind. > > PKCS#11 is API not a protocol... The API can be implemented over USB just as well as over DLL. There's really not a big difference. > In order to share the device and in order to perform device > authentication you need to define a protocol. How are devices shared and authenticated in existing p11s? > What I have in mind is to pull all objects from the device into main > computer and implement PKCS#11 locally, while delegating only private > key operations to the device. > This way you have much faster implementation, and a very simple > protocol implementation. Go for it! It's also an interesting idea. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On Tue, Apr 26, 2011 at 1:23 PM, Peter Stuge wrote: > Alon Bar-Lev wrote: >> it would be better to emulate some standard interface, such as >> serial over USB. > > Absolutely not. I would not dismiss this entirely... >> Serial over USB has the advantage to work on all modern operating >> systems, including Windows (PKCS#11 only not mini CSP). While >> implementing all logic within userspace. > > The same is true for a vendor specific USB interface thanks to libusb. > Most importantly, the vendor specific interface allows to take full > advantage of the packet based nature of USB and built-in structured > communication. The protocol comes for free and does not need to be > implemented on top of a idiotic stream emulation on top of a packet > protocol. I don't think a device that won't work in Windows, or will force writing kernel level driver is something that is usable. Also using libusb is much more difficult than using a plain tty. I really see a lot of advantages of using the most primitive channel for communication. For example, the exact same protocol may be used over TCP/SSH socket. Or can be proxied to remote ssh session. While direct usage of libusb forces local communications. >> Serial over USB has also the potential to be a very secured >> implementation. > > That's BS. No device class is more or less secure than any other. The > only purpose of device classes are to bind a common driver to the > device. In this case there exists no fitting driver, so vendor > specific is the only correct choice. The security is derived from the complexity of the implementation. Adding libusb dependency (on both sides) and more complex code of handling the device allocation, makes the probability of security issues higher. > Or maybe you suggest exposing a PKCS#15 filesystem using MSC? I thought about exposing the device using standard interfaces. Yes, accessing the file system can be done using MSC. Performing private key operations can be done using serial. However, I do not recommend of using MSC as it won't allow to proxy the device into a remote location. >> And need to deal with channel encryption secured messaging is >> not this strong... > > Encrypt away. No problem. I did not find a decent solution for this, mind to share your view? How can two parties can communicate with each other while have nothing common? PGP/SSH like manual key exchange may be used, but it is too complex for most users. >> After solving the above, it is all about PKCS#11 API serialization. >> Most of the PKCS#11 objects may be loaded into the host computer. Only >> private key operations should be serialized and sent to device in >> runtime. >> >> Proper definition of the communication interface of the device will >> enable people to provide compatible hardware. Which would be great. > > I basically have PKCS#11 over USB in mind. There may need to be a few > tweaks, but not too many I think. PKCS#11 is API not a protocol... In order to share the device and in order to perform device authentication you need to define a protocol. What I have in mind is to pull all objects from the device into main computer and implement PKCS#11 locally, while delegating only private key operations to the device. This way you have much faster implementation, and a very simple protocol implementation. However, this protocol has little to do with PKCS#11... Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
I don't know what you had in mind with an "USB P11 token" but in case you would like to participate in an effort making sort of a USB P11 token there is already a project to dig in to: http://webpki.org/auth-token-4-the-cloud.html If you take a deep peek in the extensive documentation you will note that it is not a P11 token; it is a token that will run P11 for "using" keys, but an entirely different system for "provisioning" keys. The reason for this division is that P11 represent a dead-end for provisioning since it doesn't support SM (Secure Messaging). If you look into the RI (Reference Implementation) of the token you will see that SM is piece of cake. Converting the Java code to ARM C/C++ shouldn't be much of an issue, it is only storage in NVM that requires a bit more thinking to not end-up with wear out problems. Just drop me a line if you are interested. I'm particularly interested in USB, P11, Mac, Electronics, and Browser competences. An unusual (unique?) aspect of the mentioned project is that it is designed to be integrated in browsers. Although maybe not exactly what you guys are looking for, the prime target for the project are people who are NOT interested in security or at least know very little about it! Since they represent 99% of all users it looks a bigger market :-) Anders On 2011-04-26 11:28, Alon Bar-Lev wrote: > On Tue, Apr 26, 2011 at 11:45 AM, NdK wrote: >>> I was thinking microcontroller size, but if you're using a more >>> powerful USB device hardware that can run Linux then it could be >>> realized pretty quickly using softhsm. >> Since speed is quite critical, I was thinking to use something like G20 >> Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it >> can be WAY cheaper than other solutions), but it's tiny, fast (400MHz >> ARM9), can work as USB device (and host, maybe to keep a master key on a >> standard smart card used only once at boot time), can accomodate a >> (small) display and many keys, and there's a module with an FPGA if you >> want/need to implement some crypto acceleration in HW. >> There's even an Ethernet port (better not to use it... :) ). Too bad USB >> runs at most at 12Mbps, but that shouldn't be an issue. >> >> Didn't know softhsm... I'll have a look at it. > > There is no reference for this board in the link you sent. > > It would be a great solution if the device will be very small and run Linux! > It would be lovely to have PIN keypad and BIO reader on board as-well. > > However, I want to raise some issues. > Developing an implementation that directly accesses the USB device > impose fundamental security issue. As it requires the user to have > special privilege. It is true that on modern linux, udev can deal with > some device privilege settings, but it would be better to emulate some > standard interface, such as serial over USB. > > Serial over USB has the advantage to work on all modern operating > systems, including Windows (PKCS#11 only not mini CSP). While > implementing all logic within userspace. > > It will even be possible to access these devices in remote terminal > services of Windows. > > Serial over USB has also the potential to be a very secured implementation. > > Then you need to deal with device sharing. Stateless implementation > (connect, operate, disconnect) would solve this, while creating some > authentication cookie with the device. > > And need to deal with channel encryption secured messaging is not > this strong... > > And last, power management should be applied, so device will be able > to be powered down while inactive. This should be simple if stateless > mode is used and if authentication cookies are stored in non-volatile > memory. > > After solving the above, it is all about PKCS#11 API serialization. > Most of the PKCS#11 objects may be loaded into the host computer. Only > private key operations should be serialized and sent to device in > runtime. > > Proper definition of the communication interface of the device will > enable people to provide compatible hardware. Which would be great. > > Alon > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
NdK wrote: > Fox Board ( http://acmesystems.com/ ). .it > It's surely not cheap I will probably get a gumstix board for another couple of projects, and might prototype on that. I'm not sure the final system should run Linux because it's a whole lot of code for a simple device and because it does require more expensive hardware. The more expensive boards are great for prototyping though. > Too bad USB runs at most at 12Mbps, but that shouldn't be an issue. I don't think that will be a problem, no. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Alon Bar-Lev wrote: > it would be better to emulate some standard interface, such as > serial over USB. Absolutely not. > Serial over USB has the advantage to work on all modern operating > systems, including Windows (PKCS#11 only not mini CSP). While > implementing all logic within userspace. The same is true for a vendor specific USB interface thanks to libusb. Most importantly, the vendor specific interface allows to take full advantage of the packet based nature of USB and built-in structured communication. The protocol comes for free and does not need to be implemented on top of a idiotic stream emulation on top of a packet protocol. > Serial over USB has also the potential to be a very secured > implementation. That's BS. No device class is more or less secure than any other. The only purpose of device classes are to bind a common driver to the device. In this case there exists no fitting driver, so vendor specific is the only correct choice. Or maybe you suggest exposing a PKCS#15 filesystem using MSC? > And need to deal with channel encryption secured messaging is > not this strong... Encrypt away. No problem. > After solving the above, it is all about PKCS#11 API serialization. > Most of the PKCS#11 objects may be loaded into the host computer. Only > private key operations should be serialized and sent to device in > runtime. > > Proper definition of the communication interface of the device will > enable people to provide compatible hardware. Which would be great. I basically have PKCS#11 over USB in mind. There may need to be a few tweaks, but not too many I think. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On Tue, Apr 26, 2011 at 11:45 AM, NdK wrote: >> I was thinking microcontroller size, but if you're using a more >> powerful USB device hardware that can run Linux then it could be >> realized pretty quickly using softhsm. > Since speed is quite critical, I was thinking to use something like G20 > Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it > can be WAY cheaper than other solutions), but it's tiny, fast (400MHz > ARM9), can work as USB device (and host, maybe to keep a master key on a > standard smart card used only once at boot time), can accomodate a > (small) display and many keys, and there's a module with an FPGA if you > want/need to implement some crypto acceleration in HW. > There's even an Ethernet port (better not to use it... :) ). Too bad USB > runs at most at 12Mbps, but that shouldn't be an issue. > > Didn't know softhsm... I'll have a look at it. There is no reference for this board in the link you sent. It would be a great solution if the device will be very small and run Linux! It would be lovely to have PIN keypad and BIO reader on board as-well. However, I want to raise some issues. Developing an implementation that directly accesses the USB device impose fundamental security issue. As it requires the user to have special privilege. It is true that on modern linux, udev can deal with some device privilege settings, but it would be better to emulate some standard interface, such as serial over USB. Serial over USB has the advantage to work on all modern operating systems, including Windows (PKCS#11 only not mini CSP). While implementing all logic within userspace. It will even be possible to access these devices in remote terminal services of Windows. Serial over USB has also the potential to be a very secured implementation. Then you need to deal with device sharing. Stateless implementation (connect, operate, disconnect) would solve this, while creating some authentication cookie with the device. And need to deal with channel encryption secured messaging is not this strong... And last, power management should be applied, so device will be able to be powered down while inactive. This should be simple if stateless mode is used and if authentication cookies are stored in non-volatile memory. After solving the above, it is all about PKCS#11 API serialization. Most of the PKCS#11 objects may be loaded into the host computer. Only private key operations should be serialized and sent to device in runtime. Proper definition of the communication interface of the device will enable people to provide compatible hardware. Which would be great. Alon ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 09:51, Peter Stuge ha scritto: > NdK wrote: >> One of the projects on my TODO list (quite a long list :( ) is to >> implement a suitable interface (CCID+virtual token? Could be better to >> opt for something that doesn't require APDUs...) on an embedded system >> w/ USB device interface... > Right. This is the idea for a USB p11 token that I've been going on > about for a long time already. :) We could start a parallel project, then :) > I was thinking microcontroller size, but if you're using a more > powerful USB device hardware that can run Linux then it could be > realized pretty quickly using softhsm. Since speed is quite critical, I was thinking to use something like G20 Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it can be WAY cheaper than other solutions), but it's tiny, fast (400MHz ARM9), can work as USB device (and host, maybe to keep a master key on a standard smart card used only once at boot time), can accomodate a (small) display and many keys, and there's a module with an FPGA if you want/need to implement some crypto acceleration in HW. There's even an Ethernet port (better not to use it... :) ). Too bad USB runs at most at 12Mbps, but that shouldn't be an issue. Didn't know softhsm... I'll have a look at it. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
NdK wrote: > One of the projects on my TODO list (quite a long list :( ) is to > implement a suitable interface (CCID+virtual token? Could be better to > opt for something that doesn't require APDUs...) on an embedded system > w/ USB device interface... Right. This is the idea for a USB p11 token that I've been going on about for a long time already. :) I was thinking microcontroller size, but if you're using a more powerful USB device hardware that can run Linux then it could be realized pretty quickly using softhsm. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
