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 [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
