Register Agent

Agents?

Wikipedia has a great article here∞ about agents in the context of software. I suppose that I'm not actually using an agent - or at least not a particularly intelligent agent. It IS an agent by the following reason:

• The negotiations are mostly autonomous
• It solves complex negotiations, and serialization "automagically"
• It's not really a data object (although, it does have data), it's not a UI object and it doesn't really fit inside the system except as to give context and talk to other systems

So, hopefully you'll forgive me if I call this an agent. Perhaps you can downgrade the term and think of it as a dumb agent.

Identification and Authentication services

My current thought is that I'll use the JCE (javax.security) to use something like X.509 for authentication and identification. The first time a terminal connects with the default properties, it'll ask the user what the register number is and some information that might be useful for the X.509 (OU, location) and attempt to grab a new keypair from the server. If there is already a pair generated for the terminal it'll ask for an override password, and if credentials are accepted, it'll transmit the key stored on hand for that terminal which will then be stored on the local FS and the fingerprint of that key will be shoved in the properties file for the next time it starts up. If, for some reason, a terminal has a properties file with a fingerprint but no key you'll need a manager override - or you can request a new key and let it know the terminal has changed.

Assuming that you have a key, the client will request a challenge from the server (we're going to trust a lot here - this should be on a secure network segment to prevent things like man-in-the-middle attacks) in the form of a cookie or a signature that the client should be able to decrypt. I'm currently debating how much to hardcode regarding server credentials - the client will need to be able to fetch the pubkey from the server, and store the fingerprint in the properties file. I think there'll be a spot for manager overrides here.

X.509 provides a couple features: identification via signatures, encryption via RSA and then the associated useful identification information - such as being able to encode store locative information in a meaningful way. The server will also have to act as a CA. The server will store copies of both keys for the register for recovery purposes - this will be a point of vulnerability, but by the time someone can compromise this store you probably have bigger issues. It's all about reasonable failure - don't reinforce doors if walls are made of cardboard.

Serialization, preferences etc

The register will query the server for all kinds of things, including reports. This should hopefully minimize theft by keeping a transaction log, and a known good copy of the register state on the server. It'll also allow for recreation of any information because the server will basically shadow the register agent (that is, store a copy) such that if you ever need to get one back out, all you need is the keypair for authentication.

On register open, the register will check itself and see if it needs to grab a serialized copy from the server. Perhaps the register will just grab one anyway, with the latest prefs. I'm not quite sure what needs to be serialized and stored. I'm guessing the global register prefs (pos.conf) should be stored globally and distributed per register. Perhaps with register agent groupings.

Physical Tokens

It might be nice to allow user-based interaction with either RNG keygens (like RSA proposes), or with phyiscal manifestations of keypairs - such as having a keypair on a card you can scan or use as a smartcard. Any time a user needs to identify, or override, they can use a device and swipe it and improve throughput. Obviously this has a vulnerability cross-section of lost cards, loaned cards or borrowed cards, but no more than a UID/pass based solution. This does however introduce a security barrier because someone needs to forge one of your cards to gain access to a terminal, and it also provides a revocation list/repository for keys. You can also combine these keys into other sections of your business.

The downside is that scanners can be expensive, cards can be expensive and RNG keyfobs can be yet more expensive. I think that it may be of benefit to just use a barcode with a UID or possibly a password encoded on it - the cost is a piece of paper, printing a barcode and using whatever scanner you already possess.




As you can see, this is probably the most complex part of the app, so it benefits from more clarification of the process. Some UML may end up coming in handy here. More to be posted.

---

This page is CategoryJPoS