Re: [opensc-devel] new releases before xmas?
Andreas Jellinghaus wrote: Hi, maybe I can find some time to at least put out some new releases of everything (that has changes). is this a good idea? are there any patches waiting for a merge? and show-stopper bugs we should fix before (or patched to undo if they don't work ok right now)? I tried to compile latest bits from svn and check how it works with rutoken i get error: PKCS11 function C_CreateObject failed: rv = CKR_ATTRIBUTE_VALUE_INVALID (0x13) then i tried to write back signed cert steps: 1) format card $ pkcs15-init -E -p rutoken Using reader with a card: ruToken driver 2) generate key pair $ pkcs11-tool --keypairgen --key-type rsa:2048 --login --label user --id 1 Please enter User PIN: Key pair generated: Private Key Object; RSA label: user ID: 01 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: user ID: 01 Usage: encrypt, verify, wrap 3) generate csr and sign it $ openssl req -engine pkcs11 -keyform engine -key 1 -new -text -out newcert.csr -subj /CN=User engine pkcs11 set. PKCS#11 token PIN: $ openssl x509 -req -days 365 -in newcert.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out newcert.crt Signature ok subject=/CN=User Getting CA Private Key $ openssl x509 -in newcert.crt -outform der -out newcert.der 4) try to write it back $ pkcs11-tool -w newcert.der --type cert --login --label user --id 1 Please enter User PIN: error: PKCS11 function C_CreateObject failed: rv = CKR_ATTRIBUTE_VALUE_INVALID (0x13) Aborting. last step with debug output: [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_TOKEN = TRUE [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_VALUE = 308203DA308201C2020101300D06092A864886F70D01010505003057310B3009 [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_CLASS = CKO_CERTIFICATE [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_CERTIFICATE_TYPE = CKC_X_509 [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_LABEL = user [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_ID = 01 [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_SUBJECT = 300F310D300B0603550403130455736572 [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_ISSUER = 3057310B3009060355040613025255311330110603550408130A536F6D652D53 [opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): CKA_SERIAL_NUMBER = 020101 [opensc-pkcs11] card.c:285:sc_lock: called [opensc-pkcs11] reader-openct.c:420:openct_reader_lock: called [opensc-pkcs11] card.c:668:sc_card_ctl: called [opensc-pkcs11] card-rutoken.c:1389:rutoken_card_ctl: called [opensc-pkcs11] card-rutoken.c:1435:rutoken_card_ctl: SC_CARDCTL_LIFECYCLE_SET not supported [opensc-pkcs11] card-rutoken.c:1436:rutoken_card_ctl: returning SC_ERROR_NOT_SUPPORTED [opensc-pkcs11] card.c:675:sc_card_ctl: card_ctl(4) not supported [opensc-pkcs11] card.c:532:sc_select_file: called; type=2, path=3f0050154946 [opensc-pkcs11] card-rutoken.c:383:rutoken_select_file: called [opensc-pkcs11] card-rutoken.c:391:rutoken_select_file: path = 3f 00 50 15 49 46 type = 2 [opensc-pkcs11] apdu.c:516:sc_transmit_apdu: called [opensc-pkcs11] card.c:285:sc_lock: called [opensc-pkcs11] card.c:312:sc_unlock: called [opensc-pkcs11] card-rutoken.c:220:rutoken_check_sw: File (DO) not found [opensc-pkcs11] card-rutoken.c:221:rutoken_check_sw: sw1 = 6a, sw2 = 82 [opensc-pkcs11] card-rutoken.c:469:rutoken_select_file: returning with: -1201 [opensc-pkcs11] card.c:554:sc_select_file: returning with: -1201 [opensc-pkcs11] profile.c:317:sc_profile_load: Trying profile file /usr/share/opensc/pkcs15.profile [opensc-pkcs11] profile.c:325:sc_profile_load: profile /usr/share/opensc/pkcs15.profile loaded ok [opensc-pkcs11]
Re: [opensc-devel] new releases before xmas?
Hi Pavel, can you check with the rutoken authors? not sure if they follow this mailing list. I neither have a token nor documentation (nor time right now), so I can't be of any help. rutoken is a new driver, so if it is not working 100% so far, that is not a show stopper for the next release. but of course it would be much better, if it worked. * card-rutoken.c: Support for Rutoken cards * * Copyright (C) 2007 Pavel Mironchik ruto...@rutoken.ru * Copyright (C) 2007 Eugene Hermann ruto...@rutoken.ru I hope they can help! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new releases before xmas?
not sure if they follow this mailing list. pkcs11-tool for Rutoken S is not yet supported (have problems). pkcs15-tool is supported (almost all options). Andreas Jellinghaus: Hi Pavel, can you check with the rutoken authors? not sure if they follow this mailing list. I neither have a token nor documentation (nor time right now), so I can't be of any help. rutoken is a new driver, so if it is not working 100% so far, that is not a show stopper for the next release. but of course it would be much better, if it worked. * card-rutoken.c: Support for Rutoken cards * * Copyright (C) 2007 Pavel Mironchik ruto...@rutoken.ru * Copyright (C) 2007 Eugene Hermann ruto...@rutoken.ru I hope they can help! Regards, Andreas ___ 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
[opensc-devel] new releases before xmas?
Hi, maybe I can find some time to at least put out some new releases of everything (that has changes). is this a good idea? are there any patches waiting for a merge? and show-stopper bugs we should fix before (or patched to undo if they don't work ok right now)? alon, can you check if trunk is building ok with mingw? thanks. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new releases before xmas?
Am Mittwoch, 17. Dezember 2008 20:20:17 schrieb Alon Bar-Lev: Windows (32bit, 64bit) build is OK. As we discussed in the mailing list, I don't like the new addition martin added to pkcs11-tool, adding new standalone option --list-token-slots instead of modifier to --list-slots... No blocker, but change in interface of tools should be considered as static. I have no opinion on this. Whatever code looks cleaner might be a nice way to decide this? And there is the data object issue, which I think is a major security issue 1.) can someone check all profiles if this affects all cards? 2.) is this change in flex.profile good enought to fix new cryptoflex cards? 3.) is there a way we can fix old cryptoflex cards? if 1) is not true, we need to fix the other cards as well. it would be perfect if we could create a test procedure, and ask each card maintainer to verify that. (e.g. initialize, store data object with --private, find out the filename, use opensc-explorer to read the card without entering a pin - if it works, there is a problem). if that is the correct test procedure, we can use it to check 2.). I have no clue about 3.). maybe a new option for some tool and a few lines of code to read the ACL, and tell is wrong, insecure, then ask for the PIN, verify it, and change the ACL. well in theory, don't know such code well... also I wonder: is there any reason why the old situation is sane? I would think if there is a pin, all data on every card is write-protected by that pin (the only question is: user pin or SO pin?). and read should be either public (for public object) or private (for private objects). hmm, wait... what is the use for the 4600 directory? is it used for public and private data objects, or for private data objects only? the later would be ok - an embarrassing security bug, but easy to fix. but if we use the same directory for both types of data objects we have a problem: that won't work with directory ACL only. if the later: a) can we change the system and have two separate directories? that would be nice long term, but make it hard or impossible to fix the situation for existing cards. b) if we need to store those objects in the same directory, but our implementation allows only directory level ACLs (if we only used them so far, a change would affect each driver), then we should dodge the bullet for now, and disable private data objects (both in tools and pkcs#11), till we can properly implement them. in any case, we need to know what our situation exactly is. I don't know cryptoflex well, don't know pkcs#15 well, have no clue about the other drivers (only minor clue about cardos and nothing else), don't know enough about opensc internals. so please everyone help in getting a clear description about the situation. then we should - try to fix it for new cards - try to fix old cards with a tool if it is possible - create a patch containing these changes - write a security advisory with our analysis of the situations and the fixes - find people to proofread it and spell check it - create a new release - create new windows build and sca releases - publish the security advisory pointing to the new release and the patch - contact distributions, so they can update the binary packages for linux did I forget something? any suggestions for a different procedure? ugh. some work ahead. lots of work if we want to get this done before xmas. ouch. is my analysis and plan ok? as you can see, I need a lot of help with code and analysis of our situation and the changes needed. I can try to help by testing some cards I have and if someone posts the APDUs needed to fix it, I can try writing some code doing that (but I have no clue about our pin handling stuff, hope that isn't too hard). also I can create a release and test etc. can you help with some of the items, so we can work together to fix it? thanks for your help everyone! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new releases before xmas?
On 12/17/08, Andreas Jellinghaus a...@dungeon.inka.de wrote:
As we discussed in the mailing list, I don't like the new addition
martin added to pkcs11-tool, adding new standalone option
--list-token-slots instead of modifier to --list-slots... No blocker,
but change in interface of tools should be considered as static.
I have no opinion on this. Whatever code looks cleaner might be
a nice way to decide this?
Well.. Apparently I am the only one with opinion... so I redraw.
And there is the data object issue, which I think is a major security issue
1.) can someone check all profiles if this affects all cards?
Except of oberthur.profile all profiles has one way or another:
EF data {
ACL = READ=NONE.*;
}
So it affects all the cards, I don't fully understand the oberthur...
2.) is this change in flex.profile good enought to fix new cryptoflex cards?
If I understand correctly, this change will make all data objects
private. We do not want this. We want to support public and private
data objects.
snip
in any case, we need to know what our situation exactly is.
I don't know cryptoflex well, don't know pkcs#15 well,
have no clue about the other drivers (only minor clue about
cardos and nothing else), don't know enough about opensc internals.
so please everyone help in getting a clear description about the
situation.
My either... :(
I thought I will be able to invest some time to investigate this in
the near future.
But we need someone who knows PKCS#15 good enough to decide.
then we should
- try to fix it for new cards
- try to fix old cards with a tool if it is possible
- create a patch containing these changes
- write a security advisory with our analysis of the situations
and the fixes
Well... is there any active PKCS#15 developer left in OpenSC domain?
- find people to proofread it and spell check it
This I can do... :)
I have the same issue with asepcos.
- create a new release
- create new windows build and sca releases
- publish the security advisory pointing to the new release and the patch
- contact distributions, so they can update the binary packages for linux
The above is simple enough... :)
Thanks!
Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new releases before xmas?
Hi. I have a bunch of other code changes waiting to be sent for comments/ commiting before beginning of january but I've been pre-occupied with my 1st son who arrived (a bit early) a week ago, so the work has to wait a bit yet there is a deadline of 2nd of January. The list-token thing of course should be reduced to -T only, which affects the related C_GetSlotList parameter (for all calls) m. On 17.12.2008, at 22:05, Andreas Jellinghaus wrote: Am Mittwoch, 17. Dezember 2008 20:20:17 schrieb Alon Bar-Lev: Windows (32bit, 64bit) build is OK. As we discussed in the mailing list, I don't like the new addition martin added to pkcs11-tool, adding new standalone option --list-token-slots instead of modifier to --list-slots... No blocker, but change in interface of tools should be considered as static. I have no opinion on this. Whatever code looks cleaner might be a nice way to decide this? And there is the data object issue, which I think is a major security issue 1.) can someone check all profiles if this affects all cards? 2.) is this change in flex.profile good enought to fix new cryptoflex cards? 3.) is there a way we can fix old cryptoflex cards? if 1) is not true, we need to fix the other cards as well. it would be perfect if we could create a test procedure, and ask each card maintainer to verify that. (e.g. initialize, store data object with --private, find out the filename, use opensc-explorer to read the card without entering a pin - if it works, there is a problem). if that is the correct test procedure, we can use it to check 2.). I have no clue about 3.). maybe a new option for some tool and a few lines of code to read the ACL, and tell is wrong, insecure, then ask for the PIN, verify it, and change the ACL. well in theory, don't know such code well... also I wonder: is there any reason why the old situation is sane? I would think if there is a pin, all data on every card is write- protected by that pin (the only question is: user pin or SO pin?). and read should be either public (for public object) or private (for private objects). hmm, wait... what is the use for the 4600 directory? is it used for public and private data objects, or for private data objects only? the later would be ok - an embarrassing security bug, but easy to fix. but if we use the same directory for both types of data objects we have a problem: that won't work with directory ACL only. if the later: a) can we change the system and have two separate directories? that would be nice long term, but make it hard or impossible to fix the situation for existing cards. b) if we need to store those objects in the same directory, but our implementation allows only directory level ACLs (if we only used them so far, a change would affect each driver), then we should dodge the bullet for now, and disable private data objects (both in tools and pkcs#11), till we can properly implement them. in any case, we need to know what our situation exactly is. I don't know cryptoflex well, don't know pkcs#15 well, have no clue about the other drivers (only minor clue about cardos and nothing else), don't know enough about opensc internals. so please everyone help in getting a clear description about the situation. then we should - try to fix it for new cards - try to fix old cards with a tool if it is possible - create a patch containing these changes - write a security advisory with our analysis of the situations and the fixes - find people to proofread it and spell check it - create a new release - create new windows build and sca releases - publish the security advisory pointing to the new release and the patch - contact distributions, so they can update the binary packages for linux did I forget something? any suggestions for a different procedure? ugh. some work ahead. lots of work if we want to get this done before xmas. ouch. is my analysis and plan ok? as you can see, I need a lot of help with code and analysis of our situation and the changes needed. I can try to help by testing some cards I have and if someone posts the APDUs needed to fix it, I can try writing some code doing that (but I have no clue about our pin handling stuff, hope that isn't too hard). also I can create a release and test etc. can you help with some of the items, so we can work together to fix it? thanks for your help everyone! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
