Re: [opensc-devel] OpenDNIe project is now ready for public test
Hello, On Mon, Apr 25, 2011 at 15:33, jons...@terra.es jons...@terra.es wrote: About User Consent AKA popping up notice windows about what the user is about to do as well as ticket #232 [1]. I still believe that it is mostly politics to delegate responsibility :) What it tries to protect from or inform the user of, the chosen technical mechanism is IMHO far from being enough. From purity vs practicality point of view, in the context of PKCS#11 applications for example, it would be the responsibility of the application to display application specific notices if the signature to be given is in fact given with an application that is meant for giving digital binding signatures. For example, NSS thinks that non-repudiation keys are OK for web authentication, giving a popup about legally binding signatures if the end result is a SSL session is not appropriate. You're right, but in the Real World very few apps take care on these items as they should For instance: OpenOffice doesn't ask user approval for signing documents; ever worse: doesn't check key usage flag on the selected certificate. In the testing process of DNIe I've found too many apps that silently sign documents... All these funny apps made me change my opinion about user consent (Notice that OpenDNIe does not ask user pin: only uses popup windows to ask confirmation for the signature procedure, just before sending proper APDU) Yes, there are reasons for such notifications, in this case too loosely implemented existing applications and a fix by patching solution to filter such possibly unwanted operations (which usually do NOT result in a binding contract). Yet I've heard that there are policies in some countries where the popups are designed as legal requirements to technically (?) protect from unwanted signatures or to have a certified legal warning for signature operations. Which are worthless, as long as a piece of software on the host computer can still create a silent signature by knowing the user PIN code. If there are no hardware based elements in this scheme, the idea is useless. Nothing can force a piece of malware to use the official PKCS#11 module or equivalent if they can send arbitrary APDU-s directly to the card instead [1]. Also, It might soon become as annoying as are you sure you want to quit? windows of some applications that don't have the don't ask this again option Nevertheless, the feature has usage scenarios (like fulfilling questionable policies). Some things to consider: * Where to implement it. Current implementation in a card driver is not the right place maybe, if the driver is used from a Tokend, a PKCS#11 or minidriver, GUI availability can vary. Thus it should be possible to control it based on an interface driver (PKCS#11 vs minidriver for eample) rather than card driver. So your proposal is create a separate file to store all user consent operations, and call them when required. I agree: that's the way to work Yes, GUI related bits and pieces (which depend on the platform) should be split into a separate entity, be it a file, a namespace or something else. (There used to be ui.h/ui.c which did not do much). But the important differentiation would be to implement it on the interface driver level (PKCS#11, Tokend or minidriver), because they all fit differently to the overall system. Indicating the need for user consent can be done in individual card drivers (if the PKCS#15 user_consent field is not enough to tune it) * What to show to the user (and how). This includes i18n. i18n is not only related to user consent: any xxx-tool are also candidates. Afaik Belpic card has also same i18n issues (btw no i18n ticket found) Agreed. * Integration with the rest of the platform. I really like the concept of trusted windows or stuff that is controlled by the system and harder to fake for malware like the Windows UAC. OS X and Windows have mechanisms for this, although I'm not sure if/how difficult it is to jack into them. On Linux, maybe GnomeKeyring can provide some help (for Gnome desktops)? If the feature is to be enabled, it would probably be used in a desktop environment, so tuning for a smooth and integrated experience would be of great value. A problem arises in Linux: dependancy with external libraries at compile time. I've solved it in linux by using pinentry as an external tool, without libassuan, and declare in config file how to process and wich program to use Dependencies are not bad per se, it is just that they should be evaluated for a good purpose. Creating a GUI will anyway create dependencies, be them runtime or compile time ones. libassuan was only used to trigger a GUI in the mozilla-signer module. Maybe libassuan *is* the most appropriate tool on Linux for example, I don't know. The description for it tells Libassuan is the IPC library used by some GnuPG related software. which does not seem to suggest that it should be the best tool
Re: [opensc-devel] --insecure ?
Hello, On Mon, Apr 25, 2011 at 12:01, Viktor TARASOV viktor.tara...@opentrust.com wrote: Personally, I'm ready to remove at all 'insecure' option -- never used it. All the stuff can be defined in the card profile. But let us wait for the other opinions. I've used it and I find it a generally useful option, for cases where the card could get reset yet where the access to the key can be controlled with physical means (like a server with a token, where you'll just revoke the necessary certificates when the machine should be stolen and controlled access to the key is not as necessary). The problem is that it is not equally supported by card drivers and always not well supported by applications (which insist on using C_Login before any operations, disregarding CKF_LOGIN_REQUIRED) I don't know quite well the world of 'controlled/trusted environment', my interest is rather to administrate the card through the 'uncontrolled/untrusted' environment. That's a good philosophical difference. IMO the default security officer profile of OpenSC is not OK for home users either and the default could be onepin profile. More advanced (but still small setups) could set up different PIN profiles for card management (like the scheme described by Diego) and even bigger setups default to the most complicated scheme that will require further key management to maintain (your interest). This should be documented more nicely so that people who don't know the field or who know what they'd want to implement would know what to do and expect from OpenSC. Cheers, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
Il 26/04/2011 08:41, Martin Paljak ha scritto: Personally, I'm ready to remove at all 'insecure' option -- never used it. All the stuff can be defined in the card profile. But let us wait for the other opinions. I've used it and I find it a generally useful option, for cases where the card could get reset yet where the access to the key can be controlled with physical means (like a server with a token, where you'll just revoke the necessary certificates when the machine should be stolen and controlled access to the key is not as necessary). The That's another interesting use, but on a server you'll usually need faster tokens (unless it's really low-traffic). 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... problem is that it is not equally supported by card drivers and always not well supported by applications (which insist on using C_Login before any operations, disregarding CKF_LOGIN_REQUIRED) That's an app bug and to be reported as such. Trying to fix it at the wrong level doesn't do any good. But, for example, ssh doesn't require it unless the key is protected (but then it leaves the card in unusable state). But generating a protected key when --insecure is specified is a bug in opensc (or in the card driver). IMHO. Since you used --insecure, can you confirm that its misbehaviour is only for MyEID cards? I don't know quite well the world of 'controlled/trusted environment', my interest is rather to administrate the card through the 'uncontrolled/untrusted' environment. That's a good philosophical difference. IMO the default security officer profile of OpenSC is not OK for home users either and the default could be onepin profile. Well, I think that at least two PINs are always a good idea: one for *use* and one for *administration*, so the user is forced to know he's doing something dangerous. If he doesn't like to remember'em, then he could simply use the same code for both. But having only one is, IMVHO, a really bad idea, just like using 'root' for browsing the web. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --list-public-keys
Le lundi 25 avril 2011 à 22:53 +0200, NdK a écrit : pkcs15-tool -D should list 'em all, or not? A dump, oh sure, in hexadecimal or better binary. :) On the same vein: --list-public-keys does not read public keys derived from RSA private keys. --read-public-key arg reads public keys derived from RSA private keys. --read-ssh-key reads public keys derived from RSA private keys. All this is confusing for users. At present, --list-public-keys fails to locate all usable keys. Unless you are an expert, you cannot know that. And pkcs15-tool should not be only for experts. I still believe that pkcs15-tool --list-public-keys is a commitment to list all RSA keys usable as public keys. Maybe a switch should indicate independent object or virtual object when derived from a private key. This is only an idea. Tell me what I should do. If users really need to read dumps, I will ask them to read dumps. No kidding this time. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ 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
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 ndk.cla...@gmail.com 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
On Tue, Apr 26, 2011 at 1:23 PM, Peter Stuge pe...@stuge.se 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
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] pkcs15-tool --list-public-keys
Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit : pkcs15-tool is a (G)UI as well. And to my knowledge it does what it advertises. After a short discussion with Martin, I post the steps to reproduce: Initialize the Feitian PKI: * pkcs15-init -E * pkcs15-init --create-pkcs15 --profile pkcs15+onepin --use-default-transport-key --pin --puk 11 --label François Pérou Now find certificate including: one RSA private key, one X.509 certificate and CA certs. Online CAs provide such format. Import in key: * pkcs15-init --store-private-key key-file.p12 --format pkcs12 --auth-id 01 --pin Dump, we have no public object, which is normal: pkcs15-tool --dump Using reader with a card: Feitian SCR301 00 00 PKCS#15 Card [François Pérou]: Version : 0 Serial number : 2963094713181210 Manufacturer ID: EnterSafe Last update : 20110220103102Z Flags : EID compliant PIN [User PIN] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x32], local, initialized, needs-padding Length : min_len:4, max_len:16, stored_len:16 Pad char : 0x00 Reference : 1 Type : ascii-numeric Path : 3f005015 Private RSA Key [Private Key] Object Flags : [0x3], private, modifiable Usage : [0x10E], decrypt, sign, signRecover, derive Access Flags : [0x0] ModLength : 2048 Key ref : 1 Native : yes Path : 3f005015 Auth ID : 01 ID : 2649a19d5d6a216913c5a0c8bb9f97229dec99ab X.509 Certificate [/CN=***/emailAddress=@***] Object Flags : [0x2], modifiable Authority : no Path : 3f0050153100 ID : 2649a19d5d6a216913c5a0c8bb9f97229dec99ab Encoded serial : 02 03 00C520 X.509 Certificate [/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root] Object Flags : [0x2], modifiable Authority : yes Path : 3f0050153101 ID : ef47e5fca7e04e356d41b0192d725eb0e54fc3af Encoded serial : 02 01 01 X.509 Certificate [/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=supp...@cacert.org] Object Flags : [0x2], modifiable Authority : yes Path : 3f0050153102 ID : c81e42ceda0bc1d65c9051b0eb8679e29dd6c067 Encoded serial : 02 01 00 Now, we come to the point: * pkcs15-tool --list-public-keys returns nothing * pkcs15-tool --read-public-key c81e42ceda0bc1d65c9051b0eb8679e29dd6c067 returns the public key From a user point of view, this is an inconsistency. In my previous emails, I was suggesting that pkcs15-tool --list-public-keys may return all usable keys, even when public objects don't exist on card. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ 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 ndk.cla...@gmail.com 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] pkcs15-tool --list-public-keys
For example: What should happen when trying to delete such (nont existing) public key object? On Tue, Apr 26, 2011 at 16:38, Martin Paljak mar...@martinpaljak.net wrote: Hello, 2011/4/26 Jean-Michel Pouré - GOOZE jmpo...@gooze.eu: Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit : pkcs15-tool is a (G)UI as well. And to my knowledge it does what it advertises. Now, we come to the point: * pkcs15-tool --list-public-keys returns nothing * pkcs15-tool --read-public-key c81e42ceda0bc1d65c9051b0eb8679e29dd6c067 returns the public key This is because of http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-tool.c#L649 From a user point of view, this is an inconsistency. In my previous emails, I was suggesting that pkcs15-tool --list-public-keys may return all usable keys, even when public objects don't exist on card. The shortest fix is adding proper documentation about what --read-public-key does, and that it makes a shortcut to the certificate if it does not find a public key object with the given ID. Generic education (instead of application feature) that certificates contain public keys does not hurt anyone either I think. Fetching a public key from a certificate is already a convenience feature. For the sake of purity, I don^t think that --list-public-keys should display a fake public key object, which does NOT exist on the card in relevant PKCS#15 structures. but patches for documentation are most welcome. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --list-public-keys
Le mardi 26 avril 2011 à 16:38 +0300, Martin Paljak a écrit : For the sake of purity, I don^t think that --list-public-keys should display a fake public key object, which does NOT exist on the card in relevant PKCS#15 structures. but patches for documentation are most welcome. I understand your point of view. 1) IMHO the public key really exists on card as soon as it derives from the private key. This is the duality of asymmetric key encryption. 2) The discussion whether a public key should exist as an independent object to be listed is secondary. From a user point of view, we should be able to ask What are all available public keys?. What is important is that users are going to use the public key. Telling users No there is no public key because of a technical issue X is nonsense from a usage point of view but also in crypto. 3) Now about your question on deletion: clearly, virtual public keys should not be deleted. You have to delete the private key. 4) To make a comparison, take the example of a driver and a car maker. The car maker believes the car should not include the airbag because the speed limit is 50 km. But drivers are going to drive faster than 50 km as they need to go to work. So should we include an airbag or not. What is important is what users are going to do with the car. So we really need to stick to reality and get the airbag. The same happens with OpenSC. People are going to use OpenSSH or VPN X/Y and they need to know which public keys they are going to use, quickly. Thinking they can access OpenSC documentation and get education is not the right way to analyse the problem. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --list-public-keys
Jean-Michel Pouré - GOOZE wrote: For the sake of purity, I don^t think that --list-public-keys should display a fake public key object, which does NOT exist on the card in relevant PKCS#15 structures. but patches for documentation are most welcome. I understand your point of view. 1) IMHO the public key really exists on card as soon as it derives from the private key. This is the duality of asymmetric key encryption. Your HO doesn't trump facts. :) pkcs15-tool is a tool that works with PKCS#15 data. If no public key exists within PKCS#15 then pkcs15-tool must not display a public key. (Again) I think the answer is to create a new, slightly higher-level tool that does what you and users want, and hides some of the PKCS#15 details. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --read-public-keys
El mar, 26-04-2011 a las 16:25 +0200, Jean-Michel Pouré - GOOZE
escribió:
Le mardi 26 avril 2011 à 16:38 +0300, Martin Paljak a écrit :
For the sake of purity, I don^t think that --list-public-keys should
display a fake public key object, which does NOT exist on the card in
relevant PKCS#15 structures. but patches for documentation are most
welcome.
I understand your point of view.
1) IMHO the public key really exists on card as soon as it derives from
the private key. This is the duality of asymmetric key encryption.
I have a similar problem with Spanish DNIe:
As you can see in wiki [1] DNIe pkcs15 stores same DF in EF(PubK) and
EF(PrivK). So pkcs15-tool --read-public-keys fails with an access
denied when trying to read public keys. The only way to retrieve
public keys is from certificate files
Looking at pkcs15-tool.c code I can see that certificate files are
only parsed when no public keys are declared in pkcs15 structure,
In DNIe, as pubk is declared, this never happens and pkcs15-tool
returns read failure
--
(from pks15-tool.c)
r = sc_pkcs15_find_pubkey_by_id(p15card, id, obj);
if (r = 0) {
if (verbose)
printf(Reading public key with ID '%s'\n,
opt_pubkey);
r = authenticate(obj);
if (r = 0)
r = sc_pkcs15_read_pubkey(p15card, obj,
pubkey);
} else if (r == SC_ERROR_OBJECT_NOT_FOUND) {
/* No pubkey - try if there's a certificate */
r = sc_pkcs15_find_cert_by_id(p15card, id, obj);
..
( the SC_ERROR_OBJECT_NOT_FOUND is never returned as DNIe says that
there is a pubk with requested id... but unreadable )
--
So what's the correct way to work:
- Take care on pkcs15-tool on read failures, and asume that private
and public key are stored together, so then go to parse certificates
- Use the pkcs15 emulation layer to hide pubk data from pkcs15, and
leave pkcs15-tool untouched
- ??? ( any other solution will be wellcomed )
Juan Antonio
[1] https://www.opensc-project.org/opensc/wiki/DNIe
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --list-public-keys
On 4/26/2011 2:25 AM, Jean-Michel Pouré - GOOZE wrote: Le lundi 25 avril 2011 à 22:53 +0200, NdK a écrit : pkcs15-tool -D should list 'em all, or not? A dump, oh sure, in hexadecimal or better binary. :) On the same vein: --list-public-keys does not read public keys derived from RSA private keys. --read-public-keyarg reads public keys derived from RSA private keys. --read-ssh-key reads public keys derived from RSA private keys. Looking at the code, the --read-* options will try and find a pubkey object, and if not found will then read a certificate and extract the public key from the certificate. In some of your earlier notes, I interpreted the term derive to be key derivation, as in PKCS#11 C_DeriveKey, and not the process used in pkcs15-tool of obtaining the public key from a certificate. All this is confusing for users. At present, --list-public-keys fails to locate all usable keys. I would say the issue would be the --read-* commands should indicate that either a pubkey file was found, or that it is obraining the pubkey from the matching certificate. Unless you are an expert, you cannot know that. And pkcs15-tool should not be only for experts. I still believe that pkcs15-tool --list-public-keys is a commitment to list all RSA keys usable as public keys. No, I would say it is listing all pub key *files* found on the card. Maybe a switch should indicate independent object or virtual object when derived from a private key. This is only an idea. The term should be public key obtained from certificate. As other e-mails have said its in the documentation, and having pkcs15-tool listing virtual object could also be confusing, as an application may not be smart enough to do the same thing and look for a certificate. Tell me what I should do. If users really need to read dumps, I will ask them to read dumps. No kidding this time. Kind regards, -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --list-public-keys
On 4/26/2011 8:10 AM, Jean-Michel Pouré - GOOZE wrote: Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit : pkcs15-tool is a (G)UI as well. And to my knowledge it does what it advertises. After a short discussion with Martin, I post the steps to reproduce: Initialize the Feitian PKI: * pkcs15-init -E * pkcs15-init --create-pkcs15 --profile pkcs15+onepin --use-default-transport-key --pin --puk 11 --label François Pérou Now find certificate including: one RSA private key, one X.509 certificate and CA certs. Online CAs provide such format. Import in key: * pkcs15-init --store-private-key key-file.p12 --format pkcs12 --auth-id 01 --pin Dump, we have no public object, which is normal: pkcs15-tool --dump Using reader with a card: Feitian SCR301 00 00 PKCS#15 Card [François Pérou]: Version : 0 Serial number : 2963094713181210 Manufacturer ID: EnterSafe Last update : 20110220103102Z Flags : EID compliant PIN [User PIN] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x32], local, initialized, needs-padding Length : min_len:4, max_len:16, stored_len:16 Pad char : 0x00 Reference : 1 Type : ascii-numeric Path : 3f005015 Private RSA Key [Private Key] Object Flags : [0x3], private, modifiable Usage : [0x10E], decrypt, sign, signRecover, derive Access Flags : [0x0] ModLength : 2048 Key ref : 1 Native : yes Path : 3f005015 Auth ID : 01 ID : 2649a19d5d6a216913c5a0c8bb9f97229dec99ab X.509 Certificate [/CN=***/emailAddress=@***] Object Flags : [0x2], modifiable Authority : no Path : 3f0050153100 ID : 2649a19d5d6a216913c5a0c8bb9f97229dec99ab Encoded serial : 02 03 00C520 X.509 Certificate [/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root] Object Flags : [0x2], modifiable Authority : yes Path : 3f0050153101 ID : ef47e5fca7e04e356d41b0192d725eb0e54fc3af Encoded serial : 02 01 01 X.509 Certificate [/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=supp...@cacert.org] Object Flags : [0x2], modifiable Authority : yes Path : 3f0050153102 ID : c81e42ceda0bc1d65c9051b0eb8679e29dd6c067 Encoded serial : 02 01 00 Now, we come to the point: * pkcs15-tool --list-public-keys returns nothing * pkcs15-tool --read-public-key c81e42ceda0bc1d65c9051b0eb8679e29dd6c067 returns the public key It should have said it did not find a pubkey, but found a certificate with a pubkey. From a user point of view, this is an inconsistency. In my previous emails, I was suggesting that pkcs15-tool --list-public-keys may return all usable keys, even when public objects don't exist on card. Kind regards, -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ 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
On 2011-04-26 14:55, NdK wrote: Il 26/04/2011 12:41, Anders Rundgren ha scritto: snip 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 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 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
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 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
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] pkcs15-tool --read-public-keys
El mar, 26-04-2011 a las 22:53 +0200, Juan Antonio Martinez escribió: [...] One option would be to remove public key files from emulation (like the Estonian eID), Perhaps I'll need some help: pkcs15-dnie.c just parses pkcs15 data from card, and patches some file paths and ID's... no clear idea about how to remove found entries from pkcs15 opensc's structures Ok, I finally did it. pkcs15-tool -D no longer shows public keys on my DNIe card pkcs15-tool trace says that no public key found, so looks for keys in cert, find it, tries to read certificate... ... And dies with security status not satisfied: Remember that DNIe requires pin to read certificates, but sc_pkcs15_read_certificate() seems that does not take care on it and dies on -1211 error... and to move the handling of certificate-pubkey to generic libopensc code. This would require filtering for duplicate objects. There is already a sc_pkcs15_pubkey_from_cert() function. ¿are you taking about that?. If yes I could try to write a patch... ... but no idea on how to handle pin required previous error. Time to sleep :-) Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --read-public-keys
Hello, On Apr 27, 2011, at 02:57 , Juan Antonio Martinez wrote: El mar, 26-04-2011 a las 22:53 +0200, Juan Antonio Martinez escribió: [...] One option would be to remove public key files from emulation (like the Estonian eID), Perhaps I'll need some help: pkcs15-dnie.c just parses pkcs15 data from card, and patches some file paths and ID's... no clear idea about how to remove found entries from pkcs15 opensc's structures Ok, I finally did it. pkcs15-tool -D no longer shows public keys on my DNIe card pkcs15-tool trace says that no public key found, so looks for keys in cert, find it, tries to read certificate... ... And dies with security status not satisfied: Remember that DNIe requires pin to read certificates, but sc_pkcs15_read_certificate() seems that does not take care on it and dies on -1211 error... pkcs15-tool recently got --verify-pin option to verify a PIN before anything else. That might work for pkcs15-tool, if documented. You could re-use PIN cache inside sc_pkcs15_read_certificate, much like everything else in libopensc/pkcs15-sec.c does as well (the actual usefulness of it might be questionable for *certificates* though, they are usually read only once) I'm not sure if there is a silver bullet solution, eventually calling application must consider the requirement a PIN code before being able to read certificates. And ideally provide a tunable for this (like what NSS does but applications don't support very well) But as I understand, *listing* certificates (not reading them, but becoming aware of their existence) works without PIN codes? This should probably help a little (compared to a situation where even becoming aware of the existence of certificates requires a PIN code) and to move the handling of certificate-pubkey to generic libopensc code. This would require filtering for duplicate objects. There is already a sc_pkcs15_pubkey_from_cert() function. ¿are you taking about that?. If yes I could try to write a patch... ... but no idea on how to handle pin required previous error. When binding to the card, looping all certificates and creating public key objects, then filtering for duplicates in the pubkey file and having fake pubkey objects after binding to the card already (so that other pieces like pkcs15-tool or PKCS#11 module would not have to do that separately) But yes, that would probably not solve the PIN issue. Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
