Stef Hoeben wrote:
...
It's certainly a bug but I don't think this is a real security problem
(unless you can you describe a practical attack using this bug). If the
CDF isn't protected you can at most delete or replace [references to]
certificates (of course this can be a denial of service attack but it
shouldn't affect security schemes using certifcates + private keys).
Guess the security problem is that anyone can add a bogus root cert and
'register' it in the CDF. If an applications then trusts such a root
cert, you
can no longer be sure who signed a mail, if it's realy the bank's web
server
you're connected to... (unless you look deeper into it then most people do)
I don't know which apps effectively trust root certs marked trusted on a
smart card, but for the ones that do there is indeed a problem.
I would consider applications which automatically trust some
root certificate stored on some token a much bigger security
problem.
Btw: according to pkcs15 annex c the directory file for the
trusted certificates should be protected by the system
(== so) pin (and iso7816-15 annex b recommends to use
external authentication to protect the trusted certs).
(BTW: the certs themselves are also left unprotected)
PS: The flex.profile sets this value to true, but setting it to
false seems to work fine for me
(so I propose to remove it -> OK???)
how many pins did you test ?
3, and with 1 key under each of them + corresponding cert chain.
But it seems the Delete ACL is set to NONE for the cryptoflex card, so
it's still
possible to delete the files and then create a new, bogus one
hmm, as we didn't specify how the opensc profile should look like
this isn't really a bug. Perhaps it's not really a wise choice
to set the delete AC to none (I would prefer to use the so-pin for
this).
-> this is another security issue, IMHO
===> What to do with it??
we need to define what the (default) opensc profile should accomplish
- no reference to the user PIN is given with "pkcs15-init -X", which
causes
sc_pkcs15_init_fixup_file() to set the corresponding ACs to NONE (!)
It looks rather nasty but I'm afraid of shacking it up so I just
added a reference
to the first user PIN in case it's not set -> comments?
why not the so-pin (if present) ?
Hm, it's indeed not there (although it doesn't seem to be necessary..)
this of course depends on how the profile should look like
But adding a set_so_pin_from_card() doesn't seem to hurt, so perhaps
it's better to do so (?)
don't know as I currently don't have the time to look at the internals
of pkcs15-lib.c
If it's OK like this, I'll commit it and wait a bit hoping for someone
to test;
actually it would be nice to tests for file ACs in a test suite
(perhaps with 'expect' + opensc-explorer)
and then check 0.9.6 and 0.10.1 as well?
if you feel the need
Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
