Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
On 11/11/2012 11:50 PM, Anthony Foiani wrote: >> certtool --generate-request --outfile req.pem --load-privkey >> "pkcs11:yyy" --load-pubkey "pkcs11:xxx" >> >> should generate a request from the objects based on a smart card. The >> pkcs11: URLs are obtained using the "p11tool --list-all --login" command. > > Nice -- thank you for the pointer! > > Unfortunately, I don't think this can work with a keypair generated on > the CC-HSM. > First, the public key is only available during the same session that > generates the pair; it disappears after the session disappears. One > can capture the public key at generation time using the instructions > provided by CardContact here: > http://www.opensc-project.org/opensc/wiki/SmartCardHsm#Generatekeypair Ouch. In that case it can be a problem. I'm not aware of a PKCS #11 way to extract the public key from a private key, after its generation. However, with the process use can use the spki file in the command I send before in place of pkcs11:xxx. You may need to use the --inder option if it is in DER format. > Second, the private key is not extractable, so the certtool won't be > able to load it from the card. (Unless "--load-privkey" actually > means "use this privkey, but it's really just a reference to doing it > on the token itself.) --load-privkey does not really load the key. It only uses the private key to sign the request without extracting it. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] obtaining a CSR for a token-generated (and locked-on-token) keypair
On 11/11/2012 03:24 AM, Anthony Foiani wrote: > Greetings. > > I'm working with a CardContact HSM, and would like to generate a > keypair on the token, then get a certificate based on that key. Hello, Your question was on openssl, but just in case someone is interested. If you have any recent version of gnutls you could simply do that by using the PKCS #11 URLs of the objects. That is: certtool --generate-request --outfile req.pem --load-privkey "pkcs11:yyy" --load-pubkey "pkcs11:xxx" should generate a request from the objects based on a smart card. The pkcs11: URLs are obtained using the "p11tool --list-all --login" command. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial support for SmartCard-HSM
On Mon, Aug 6, 2012 at 11:30 AM, Anders Rundgren wrote: > On 2012-08-06 11:23, Andreas Schwier wrote: >> I would assume, that checking constraints is the job of the RA, not the CA. >> >> Anyway, our design works the other way around: The card generates the >> CSR internally, so the RA/CA can prove the key was generated in a >> legitimate device. The device can be anywhere out in the wild. > > Which is the future for smart cards, otherwise they must be physically > distributed after provisioning. But how do you prove that the key was generated in the card? You'd need some kind of provisioning to do that. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
On Wed, Mar 21, 2012 at 11:03 PM, Peter Stuge wrote: >> progress much faster, even in the price of committing not-the-best >> solutions, > Do you find this a desirable quality for a security-related project? I don't think that this thread was about a balance of quality against quantity. The issue was that the selected reviewing process was inefficient and became a bottleneck to adding any new features. Having code lying for several months unreviewed doesn't really improve quality, it just demotivates contributors. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
On 02/17/2012 10:58 PM, Jean-Michel Pouré - GOOZE wrote: > Let us take two examples to see how OpenSC can be improved: 1) The > ePass2003 code was reviewed by Viktor and included in his branch. You > probably did not know, did not compile, did not test and therefore > Viktor's work is ignored. He needs and deserves write access to > OpenSC main GIT to speed up development. The reasons is that we need > more new features, more beta testers. [disclaimer I'm not experienced with opensc internals and comment might be wrong] This sounds pretty similar to the situation in hardware drivers which often evolve faster than the linux kernel's pace. It might be better to have a module approach for such development so that cutting edge drivers can be used with opensc without recompilation or waiting for a new opensc release. I don't know though, whether the size of the projectjustifies something like that. > 2) Take the example of Alon developments around PKCS#11. A lot of > them were ignored by OpenSSH. The reason is that when a small number > of people have a grasp on a project, strange things sometimes happen. > I would not like this to happen with OpenSC. Locking a project to a > small number of developers is not good. In cases it might be good. We rejected Alon's PKCS #11 patches on gnutls as well. You can say it was the wrong decision or so, but in the end of day the few developers responsible for the project will have to maintain it. If it is code they cannot maintain, or does not agree with the longer term plans of the project maybe the feature should be postponed. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Securing a 3DES key on smartcard
2012/1/2 Jean-Michel Pouré - GOOZE : > Dear all, > Is there a way to store a 3DES key on smartcard, so it cannot be > extracted but still be usable by OpenSSL? PKCS #11 allows that but opensc didn't support secret keys last time I checked. Symmetric keys in smart-cards could be useful for Kerberos and TLS-PSK (with C_DigestKey). However none of those two have ever been used with such smart-cards to my knowledge. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ECDSA cards
On 09/22/2011 05:31 PM, Crypto Stick wrote: > The Gnuk project [1] is working on support of ECDSA. But I expect a few > more weeks or months until a public release. > [1] http://www.fsij.org/gnuk/ Looks pretty cool. About speed wouldn't using a gmp-based rsa (e.g. from nettle) be of better performance? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initializing Feitan ePass PKI token takes over 60 seconds?
On Wed, Sep 21, 2011 at 9:59 AM, Stef Walter wrote: > Is it normal for a Gooze Feitan ePass PKI Token to take over 60 seconds > to initialize when used with PKCS#11? Mine operates much faster than that. I've noticed though that it does not operate when plugged to a usb port that does not provide enough power. Could it be that case? regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
On Fri, Sep 9, 2011 at 9:38 AM, Martin Paljak wrote: > Hello, > Autumn has started (at least in northern hemisphere) so it is time to > pull together next OpenSC release. > - ECDH support [5] Out of curiosity, are the ECDH static keys used anywhere? They remind me of the DH static keys ciphersuites in TLS that although were defined I haven't seen them being used in practice (no certificates were ever issued with such keys). regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ECDSA cards
On 09/06/2011 03:38 PM, Martin Paljak wrote: >> I'm trying to use the opensc 0.12.x ECDSA support, to allow ECDSA >> signing in gnutls via PKCS #11. However I have no such cards to test it. >> Do you have any suggestion on which card to use? (My only requirement is >> that it must be obtainable without placing a mass order) > This is a difficult requirement. I'm not aware of any, except for a > PIV card that might work but that's not available any more from > smartcarfocus.com from where I got one. In fact, it seems that even > "decent java cards" is a rarity these days... Pretty strange. I couldn't find any elliptic curve supporting smart card on the market. I'd expect them to be more widespread due to their smaller memory requirements than rsa. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] ECDSA cards
Hello, I'm trying to use the opensc 0.12.x ECDSA support, to allow ECDSA signing in gnutls via PKCS #11. However I have no such cards to test it. Do you have any suggestion on which card to use? (My only requirement is that it must be obtainable without placing a mass order) regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] banks
On 08/18/2011 11:11 AM, Hans Witvliet wrote: > Perhaps a ludicreous question, but i post it anyway... Some > creditcard companies or banks supply their customer with cards plus > pin-code in order to identify themselfs during financial > transactions. >> From my focus i presume these look like ordinary smartcards. > Can these cards also be used for anything else? These cards typically support the EMV protocol (or a subset). They have the ability to perform RSA and 3DES, so in theory there could be a vendor (or manufacturer) that releases a PKCS #11 module that allows you to access them. However, without it the operations available to an EMV card are not sufficient to "emulate" PKCS #11 (and be used in other than banking applications). regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Integrating p11-kit into pkcs11-helper?
On 08/04/2011 06:57 PM, Alon Bar-Lev wrote: Hello, In gnutls we dropped our own PKCS #11 back-end based on pakchois for p11-kit. I try to contribute to the discussion based on this experience. > pkcs11-helper targets developers who like to introduce PKCS#11 into > their application, especially for smartcard. It allows to minimize > the user interaction and maximize the object reuse. While using the > minimum set of the specification in order to allow application > compatibility with most implementation. p11-kit designed to solve > incompatibilities of modules and inappropriate implementation of > application that use PKCS#11 by providing a baseline of the PKCS#11 > spec module implementation that may proxy on or more providers. This does look like making them mutually exclusive. Would be good if a library satisfied both goals. >> * Coordinating initialization and finalizing. > You referencing a bad implemented application that is use PKCS#11 in > two independent places. A practical solution is to fix the library > implementation (such as GnuTLS) to provide some state information. How do you know that one library is in use? How can you avoid an application being linked to both p11-kit and pkcs11-helper? My experience from gnutls is that you cannot really track indirect dependencies, and you end-up having applications linked against gnutls and openssl. If both had to access a PKCS #11 token there would be a problem. >> * A standard place to put configuration of which modules to load >> and how to load them. > A PKCS#11 aware application should be expose to this information and > not let some library to hide these. I also don't like libraries like > NSS that have dependencies out side of the runtime environment the > application is creating for them. >> * Allowing pkcs11-helper to load modules from a standard location. >> Does pkcs11-helper have a concept of a module registry? If not, >> this could be a nice addition provided by p11-kit. > Same as above. I don't like these registries within a library (API). > A proxy module may have its own configuration which is fine. You can have both. Both an application interface where each application selects the modules and a system wide registry to set the system wide available libraries. This is how gnutls is using p11-kit currently. regards, Nikos PS .But for me the main user-visible contribution of p11-kit is the usage of pkcs11 urls, which prevents having applications referencing the same objects by different identifiers. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Do smart card drivers generally support more than one PKCS#11 session?
On 06/21/2011 07:59 PM, Stef Walter wrote: >> I didn't like the pinfile attribute of pkcs11-urls much, because >> its semantics are undefined. I see it as an option that could cause >> compatibility issues between libraries using URLs. That's why I >> have ignored it so far. > > Yes, I understand that the pinfile attribute is really ambiguous. > Until recently I saw it as an oddity and confusing. However I think > we can turn the ambiguity of the pinfile attribute to an advantage > (although I'm going to see if we can rename it to 'pin' on > s...@ietf.org). I've created an API in p11-kit which allows > registering of callbacks to handle specific (or any) pinfile. This > allows a UI (whether CLI or GUI) to register a pin callback. Then > gnutls (or other libraries) can detect the presence of a pinfile > attribute and use p11-kit to check if anyone has registered a > callback for that pinfile. This sounds dangerous in terms of code execution. If you put a memory address would someone be able to execute arbitrary code by modifying it? If you put an index to functions, would someone be able to manipulate index and data to perform other than the expected calculations? These might not be easy to ensure. >> Are there other alternatives to solve the issue at hand? > I've tried threading context specific callbacks throughout gnutls, > and it was a very tedious and messy exercise. I have an incomplete > patch somewhere if you're interested. What if every gnutls_pkcs11_privkey_t struct has its own pin function? Would that help? regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Do smart card drivers generally support more than one PKCS#11 session?
On 06/13/2011 11:11 AM, Stef Walter wrote: > On 06/10/2011 07:08 PM, Martin Paljak wrote: >> On Jun 10, 2011, at 13:11 , Stef Walter wrote: >>> After sleeping on this idea, I realized it won't work in certain >>> cases. In particular when the key has CKA_ALWAYS_AUTHENTICATE >>> and requires C_Login with CKU_CONTEXT_SPECIFIC. >> This is hardly the case with SSL. >> >> CKA_ALWAYS_AUTHENTICATE in OpenSC context for example is only set >> for keys that require "user consent" or usually are used for >> "nonrepudiation". Most cards I've seen can use authentication keys >> once the cardholder is verified until the card is reset or >> removed. >> >> Using such card with a pinpad reader would be impossible for web >> authentication, you'd be typing the PIN most of the time > Since the PKCS#11 URI's say that the pinfile attribute of the URI > can be determined by the application, we can build something simple > in p11-kit and register callbacks so that one component (in the same > process) can provide the pin for another (like gnutls). I didn't like the pinfile attribute of pkcs11-urls much, because its semantics are undefined. I see it as an option that could cause compatibility issues between libraries using URLs. That's why I have ignored it so far. Are there other alternatives to solve the issue at hand? regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
On Tue, May 10, 2011 at 9:40 AM, Giuliano Bertoletti wrote: > Hello Nikos, > just a few notes. > The pkcs#11 standard adresses cryptographic devices in general, not only > smart-cards which might (or might not) have a single slot. > Cryptographic devices such HSMs are capable of supporting many many slots. > Slot can also be added and removed at wish. And this is exactly the reason why they shouldn't be used for object identification and usage (the typical use-case of PKCS #11). > They're used, for example, in multi user remote signatures where you setup a > server, connect it to a device, and have thousands (even millions sometime) > of users remotely operate the device. > Typically each user has a slot assigned which is protected with its own pin. I don't fully understand the use-case but I don't really see that a mainstream and neither good example of PKCS #11 usage. You lower all the security of the PKCS #11 to security of PIN over the network? A hardware token should imply proximity and visibility to the token IMO. What is the point to have a hardware token in US to sign for me while I'm in europe? How do I know it is my token or someone else isn't signing with it? > The correct way to locate a particular user key is for the application to > query by token name (returned by C_GetTokenInfo), but this might require a > lookup that is beyond the capability of the engine. Why not? In the millions slot case you mentioned it might be a problem iterating through the available slots, but in typical cases this is not a stopper. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
On Mon, May 9, 2011 at 9:53 PM, Alon Bar-Lev wrote: > This is a matter of interpretation. > Either is not constant and user is not suppose to know of. > Apart of the special case of having a single slot, so you expect 0 I presume. > You can check which slot is what simply by using: > pkcs11-tool --list-slots --module /usr/lib/pkcs11/ To me slots and slot ids shouldn't be included in any APIs or user interfaces involving PKCS #11. They do not make sense to end-user or even the application itself. In gnutls we have "p11tool" that does operations on PKCS #11 cards without any knowledge of slots. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs11 uri reference implementation and p11-kit docs
On 03/31/2011 05:48 PM, Stef Walter wrote: > I worked on documenting some of the p11-kit stuff today. Here's the > documentation for the PKCS#11 URI reference implementation: > http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-URIs.html > And here's some docs for all of p11-kit, including the configuration > files, formats, etc. Thanks. I've updated the gnutls documentation to suggest using the p11-kit intermediate module when sharing a PKCS #11 might occur. best regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC on Android
On 01/26/2011 08:46 PM, Andreas Jellinghaus wrote: > Am Mittwoch 26 Januar 2011, um 12:12:42 schrieb Nikos > Mavrogiannopoulos: >> I don't understand what you mean by a reasonable enrollment >> system, however having seen the EMV protocol, I believe that the >> available PKCS #11 compatible smart-cards have a much higher >> security level than EMV bank cards. It seems the only criteria for >> banks evaluating protocols and technologies is their complexity. > hu? can you go into details? On EMV complexity? I suppose that you have read the 4 books describing and he numerous options that might be enabled on not. That complexity leads to attacks like the Murdoch one at: http://www.cl.cam.ac.uk/research/security/banking/nopin/ (which is not theoretical, no matter what EMVCo claims) > I learned a lot about EMV in the past 10 months, and it doesn't seem > hard to me. Of course there is a lot of complexity involved, but it > is a partly online partly offline payment system with a very complex > decission system (accept transaction offline or online or decline > based on many different factors that can be personalized as > parameters). a pure pkcs#11 card has something like 10% of the > number of features that an EMV card has? so comparing those two and > complaining about complexity seems to be quite unfair to me. Not really. If you want to protect keys you must have few operations you can verify, in order to ensure that it is only used as expected. If you make a smart card with functionality that you cannot describe in 2000 pages, then you cannot claim any security about that card. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC on Android
On Wed, Jan 26, 2011 at 12:00 PM, Anders Rundgren wrote: > External tokens on mobile phones is a difficult idea that most likely > will be marginalized by on-line schemes using embedded crypto hardware. > If there was this "One Provider" things could be OK, but it is really > the opposite, and it is also getting worse. > Unlike the external tokens that haven't a reasonable enrollment > system in spite of being on the market for decades, the embedded > solutions will be enrollable through the mobile browser. You just > have to forget NSS and PKCS #11 because they don't support on-line > enrollment of the kind that can be used by "mere mortals", and at a > security level banks could accept. I don't understand what you mean by a reasonable enrollment system, however having seen the EMV protocol, I believe that the available PKCS #11 compatible smart-cards have a much higher security level than EMV bank cards. It seems the only criteria for banks evaluating protocols and technologies is their complexity. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] rev 4853
On 11/08/2010 01:48 PM, Andre Zepezauer wrote: > I'm interested in the security attributes, that are set when the file > above is created. The simplest way to get these attributes is to use > opensc-explorer: Here it is: $ opensc-explorer OpenSC Explorer version 0.12.0-rc1 Using reader with a card: OmniKey CardMan 3121 00 00 OpenSC [3F00]> cd 5015 OpenSC [3F00/5015]> info 4946 Elementary File ID File path: 3F00/5015/4946 File size: 128 bytes EF structure: Transparent ACL for READ:N/A ACL for UPDATE: N/A ACL for DELETE: N/A ACL for WRITE: N/A ACL for REHABILITATE:N/A ACL for INVALIDATE: N/A ACL for LIST_FILES: N/A ACL for CRYPTO: N/A OpenSC [3F00/5015]> ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] rev 4853
On Sun, Nov 7, 2010 at 8:07 AM, Andre Zepezauer wrote: > Hello Nikos, > please could you post the access conditions of 3F00/5015/4946. I wounder > why the error code SC_ERROR_NOT_ALLOWED is returned. To me it seems, > that r4853 has only discovered an older bug. Hello, I don't understand what you are asking here. If you can post more information, I could help. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] rev 4853
The commit applied in svn revision 4853[0] does not allow me to
erase my feitian smart card:
$ ./pkcs15-init -E
Using reader with a card: OmniKey CardMan 3121 00 00
Couldn't bind to the card: Not allowed
The error I get from sc_select_file is -1209 and if set to zero
as before I can erase and format the card properly.
regards,
Nikos
[0] The commit:
Index: src/pkcs15init/pkcs15-lib.c
===
--- src/pkcs15init/pkcs15-lib.c (revision 4852)
+++ src/pkcs15init/pkcs15-lib.c (revision 4853)
@@ -3518,8 +3518,6 @@
if ((mem = malloc(len)) != NULL) {
r = sc_read_binary(card, 0, mem, len, 0);
}
- } else {
- r = 0;
}
if (r >= 0)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc + destroy object via PKCS #11
On 11/04/2010 09:46 PM, Nikos Mavrogiannopoulos wrote: >>> I'm trying to destroy an object I created on a Feitian PKI smart >>> card using pkcs11 calls. My result is CKR_GENERAL_ERROR. I can >>> reproduce it using the pkcs11-tool: >> On the Feitian PKI and most smartcards, objects cannot be deleted, >> per spec. This is a security feature, to make sure objects are not >> replaced by attackers. The same applies for RSA keys. > Thanks, nice to know. So I suppose the only way to delete (using PKCS > #11) is by using C_InitToken instead... And as it seems this command returns unsupported feature. It would be nice to be able to delete objects created with PKCS #11 via PKCS #11 itself. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] using a secret key
> Hello Nikos, > AFAIK only RSA is supported by OpenSC. Is this a design decision or a limitation of the supported cards? regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc + destroy object via PKCS #11
On 11/04/2010 07:05 PM, Jean-Michel Pouré - GOOZE wrote: > Le jeudi 04 novembre 2010 à 18:37 +0100, Nikos Mavrogiannopoulos a > écrit : >> I'm trying to destroy an object I created on a Feitian PKI smart >> card using pkcs11 calls. My result is CKR_GENERAL_ERROR. I can >> reproduce it using the pkcs11-tool: > On the Feitian PKI and most smartcards, objects cannot be deleted, > per spec. This is a security feature, to make sure objects are not > replaced by attackers. The same applies for RSA keys. Thanks, nice to know. So I suppose the only way to delete (using PKCS #11) is by using C_InitToken instead... regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] using a secret key
Hello, Another issue I had with opensc is when trying to use it with secret keys (symmetric ones)[0]. My feitian card says it supports 3DES and DES thus I assumed it should support storing symmetric keys as well. I tried to do: I used C_CreateObject with template: CKA_CLASS -> CKO_SECRET_KEY CKA_VALUE -> an 8 byte or 24 byte raw key CKA_TOKEN -> TRUE CKA_PRIVATE -> TRUE CKA_LABEL -> test CKA_SENSITIVE -> TRUE (I could provide source if someone is interested) Either being in a session where pin has been provided or not. Both attempts fail with generic error. So my question is, whether symmetric keys are supported with opensc? Is it a limitation of opensc or the card? (I also noticed that C_DigestKey is only a dummy) regards, Nikos [0]. My goal is to implement TLS with preshared keys using a smart-card. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc + destroy object via PKCS #11
On 11/04/2010 06:56 PM, Andre Zepezauer wrote: >> If there is any additional help I can provide on that please let me know. > $export OPENSC_DEBUG=9 > $pkcs11-tool [options] 2> file.log > But be aware of the fact, that your pin will be included in the log file. There was no additional output with OPENSC_DEBUG. I used ltrace and didn't notice any getenv() either. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] opensc + destroy object via PKCS #11
Hello, I'm trying to destroy an object I created on a Feitian PKI smart card using pkcs11 calls. My result is CKR_GENERAL_ERROR. I can reproduce it using the pkcs11-tool: "$ pkcs11-tool --delete-object --id 32f153f3e37990b08624141077ca5dec2d15faed -y pubkey --login -v Using slot 1 with a present token (0x1) Logging in to "Nikos Mavrogiannopoulos (User PI". Please enter User PIN: error: PKCS11 function C_DestroyObject() failed: rv = CKR_GENERAL_ERROR (0x5) Aborting." If there is any additional help I can provide on that please let me know. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
