KDE and smartcard support
Justin Karneges
justin at affinix.com
Wed May 23 19:44:05 BST 2007
On Wednesday 23 May 2007 5:45 am, Andreas Aardal Hanssen wrote:
> On Wednesday 23 May 2007 13:18, Justin Karneges wrote:
> > And yes, an SSL socket is orthogonal to the whole key handling stuff.
> > Even QCA::TLS is pretty well independent from the rest of QCA. I think
> > it would be quite reasonable (from a technical perspective) to be able to
> > use a completely different SSL/TLS API, such as QSslSocket, with a
> > private key obtained through QCA.
> > Let me know if you have any questions or alternate suggestions.
>
> Hm, if QCA can import and export DER or PEM ASN1 encoding, I actually think
> _that_ glue is already in place...
Hi Andreas,
For software-based private keys, serializing to DER/PEM is enough to transport
between the two key containers. However, hardware-based keys are generally
not exportable. When you sign using a private key on a smart card, you don't
pull the key off of the card. Instead, you ask the card to perform a
signature and it gives you back the computed answer. Transferring a key like
this between containers is a bit more tricky, as you can expect.
This is why I suggested having a hook for signing. Here is an example:
class QSslKeyImplementation
{
public:
virtual ~QSslKeyImplementation() {}
virtual bool sign(int signAlgo, const QByteArray &in, QByteArray *out) = 0;
};
class QCASslKey : public QSslKeyImplementation
{
private:
QCA::PrivateKey key;
public:
QCASslKey(const QCA::PrivateKey &_key) : key(_key) {}
bool sign(int signAlgo, const QByteArray &in, QByteArray *out)
{
QCA::SecureArray sig = key.signMessage(in, qtAlgoToQCAAlgo(signAlgo));
if(sig.isEmpty())
return false;
*out = sig.toByteArray();
return true;
}
};
QCA::PrivateKey pkey = ... // get from somewhere
QSslKey skey;
skey.setImplementation(new QCASslKey(pkey));
// Now you can use skey with QSslSocket
-Justin
More information about the kde-core-devel
mailing list