Can't load Mifare Classic keys until a card is on the reader

[Sam-Hall]

This seems to be a pyscard caveat. Just a minor annoyance but it seems preferable to be able to initialise the reader on startup by:

• accessing keys (preferably from a secure location)
• loading them into the reader
• scrubbing the keys from memory

Similar can be achieved by postponing this task to occur as soon as the first card is presented. This would make it important that the keys are able to be accessed in a timely fashion, which may have an impact on the choice of key storage mechanism used by the service. This is not such an issue for the busted Mifare Classic technology, but when Mifare Plus support is added, all this needs careful consideration.

[Sam-Hall]

Currently implemented attempt at responsibly managing the keys has a flaw in that hidemu doesn't notice when the user disconnects/reconnects the device, resetting keys to defaults. Hidemu thinks any keys previously loaded are still in effect, and has actually discarded them already.

In such cases, killing the daemon when reader disconnection is detected seems prudent since hidemu can not do it's job without the reader anyway. There are other more likely scenarios outside the daemon's control that currently lead to the daemon terminating, such as fast user switching and other events that cause it to lose an active user desktop. As such I'd expect this deamon to be managed by a wrapper process to ensure it's running as required. This also defers the responsibility of longer term key management to the wrapper software which may be able to do a better job then hidemu currently can.

[Sam-Hall]

This is currently as fixed as it can get without abandoning all attempts at purging keys from memory as soon as possible. The process terminates on reader disconnection to ensure keys get reissued when it's restarted.