Sophie

Sophie

distrib > Fedora > 13 > x86_64 > media > updates > by-pkgid > 64d7525dee9596ae0eae9ecd4241861b > files > 118

opensc-0.11.13-6.fc13.i686.rpm

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:html="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>
      SecureSetup – OpenSC
    </title><style type="text/css">
           @import url(trac.css);
          </style></head><body><div id="content" class="wiki">
      <div class="wikipage searchable">
        
          <h1 id="OpenSCSecurityConfiguration">OpenSC Security Configuration</h1>
<h2 id="Commandlinearguments">Command line arguments</h2>
<p>
The OpenSC tools allow you to specify PINs and keys on the command line. This is only suitable for testing or when you are the only user of the machine. If there are multiple users, other users usually are able to run things like 'ps' or 'top', and probably are able to see the arguments given to some process, too. Also, the arguments probably get logged to some shell history file like ~/.bash_history.
</p>
<p>
The solution is to use a script or, in the case of the pkcs15-init tool to put PINS and keys into a file and used through the --options-file options.
</p>
<h2 id="Accesstothecard">Access to the card</h2>
<p>
Some other problems if multiple users have access to the reader(s):
</p>
<p>
If the user forgets a card to the reader while the session isn't locked, a malicious other user could run PIN verify commands to the card and probably lock the PIN, or even lock the card for good. If a user is logged in to the card but the session isn't locked, a malicious user could use the previleged functionality (e.g. doing a signature, writing data to the card).
</p>
<p>
A solution is to add the user to a specific "scard" group after they've logged in through xdm. pcsc-lite's pcscd runs as pseudouser/group scard/scard, and limit the access to the server socket (pcscd.comm) as 770 scard:scard. This way, other possible users that may have logged in through ssh won't have any access to the local card readers. Not a perfect solution, but works for single-reader workstations well enough.
</p>
<p>
In case your application uses the pkcs11 library, that application will have, exclusive access access to the card once you provided a PIN. This is the default setting. If you would like multiple apps to use the pkcs11 library, you can set 'lock_login = false;' in the opensc.conf file, but this leaves your card open to other user's applications as well.
</p>
<p>
Other tools/libs (signer, openssh, pam) don't provide unique access once you are logged in.
</p>
<h1 id="Protectionofcardsmadewiththepkcs15-inittool">Protection of cards made with the pkcs15-init tool</h1>
<p>
Most cards have a default transport key that is used to create a pkcs15 directory on the card. Within the pkcs15 directory, files and keys are protected by PINs so the transport key has no power there.
</p>
<p>
This means that your keys and sensitive data are safe against others (who know the default transport key), in the sense that they can't be read or used.
</p>
<p>
However, depending on the smartcard os and the card profile anyone who knows the transport key and has access to your card can delete the pkcs15 directory with all it's keys, certs, data, ...
</p>
<p>
On itself, that may be a good thing if you lost your card, but there's another problem: If your card contains trusted certificates, and an adversary steals your card, puts another pkcs15 dir with other certs on the card and puts it back without you knowing, you may not find out until you put trust in those untrusted certs. Bottomline: be very carefull when using the card as a tamper-resistant storage -- make them PIN-protected for example. (Note: this if often not the case: the trusted certificates are stored usually stored in the application using them.)
</p>
<h2 id="Storingconfigprofileandpkcs15cachefiles">Storing config, profile and pkcs15 cache files</h2>
<p>
While the opensc.conf and xxx.profile files don't contain any sensitive information, it is very important that they are not tampered with.
</p>
<p>
Some examples of what an adversary with write access to those files or an absent-minded administrator could do:
</p>
<ul><li>Set the debug level to 6, which means all sensitive info (like PINs) is logged 
</li><li>Change the access conditions in the profiles, so that a card that is initialised with pkcs15-init will be wide open for anyone to read/write/sign
</li><li>Change trusted certs in the pkcs15 cache
</li></ul><p>
By default, the config and profile files can only be written by root/Adminstrator and the cache files are in the user home dir, so this is OK. Note however, that if there are profile files in the current dir, it will be those files that are used instead of the ones that were installed in a system dir!
</p>
<h2 id="Rootaccess">Root access</h2>
<p>
From the above, it follows that you can't protect your card, nor use your card to protect something against someone with root access or who can change the config/profile files, binaries or sniff/modify the communication with the card.
</p>

        
        
      </div>
    </div><div class="footer"><hr></hr><p><a href="index.html">Back to Index</a></p></div></body></html>