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 > [email protected] > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
