Hello,
I'm looking for suggestions for a security design to wrap around PC/SC.
The current version allows you to use RPC for IPC or you can link your
application directly to the resource manager and have 1 app ---> 1 reader.
The multi - application (with RPC) works the best but could be much better
with some security measures set in place. I'm going to be implementing
these soon. Here are some things to look at:
1) All transmitted APDU's will have a trailing 8 byte hash or checksum. I
may also have another hash on the response where the response not only has
the received hash from the response but also the transmittal hash so that
the application can link that response with the transmitted apdu by
comparing the hash received with the one sent.
2) Each APDU that is sent must be encrypted at the client and then
decrypted at the server. The same with responses. Card status/conection
information is not considered to be all that secretive.
2) The resource manager must authenticate any connecting process. In
other words if the resource manager gets a connection from corcoran from
127.0.0.1 (localhost) it must be able to tell if that is really corcoran
that is connecting up. I think the keys used for encryption of the APDU's
can be tied into this in some fashion or we could use temporary session
keys for each transaction. I will be adding hooks in the /etc/pcsc.conf
file in future releases where you can do a:
allow 10.0.2.222
deny 10.0.2.221
allow all
deny all
sort of mechanism for restricting access based on machine but there still
needs to be restriction on user.
One possibility is to change the SCARDCONTEXT variable from the Microsoft's
DWORD to a structure which holds key values. Basically, when you connect
to the resource manager you will be given a key for that session. This
will keep people from trying to guess values of the SCARDCONTEXT and
connect up.
Secure RPC is a joke and I guess there is supposed to be another form of
this coming soon - does anyone know more about this ?
Any ideas are welcome and will definitely be considered.
Best Regards,
Dave
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
