Technical Architecture

The above diagram shows the proposed technical architecture for the UMPEAR project. Security of the central server and the data it holds is of primary concern, hence the following security precautions:

1. The client software MSIL will be obfuscated using a commercial strength obfuscator.
2. Requests to the central server are made through a publicly accessible webservice, the public facade, via HTTPS. These requests are then forwarded on to a private webservice, also via HTTPS and through an IP restrictive firewall. Once here, the requests are dealt with by the data managers, which communicate with the database via a trusted connection.
3. Over and above the HTTPS encryption, the Client UI will request a triple DES encrypted time sensitive token based on elements uniquely identifing the calling computer, which will be exchanged during each webservice call, in order to authenticate the calling UI.
4. All data fields within the database will be encrypted using Rijndael and all records will incorporate an MD5 checksum in order to highlight unauthorised modification, which will be dealt with by the Sentinel services (see below).
5. All data actions (insert, update and delete) will be fully audited, using double entry auditing, with the before and after images posted to different databases.
6. In addition, semi autonomic Sentinel services will constantly monitor the state and validity of the data across all data repositories, repairing where necessary & alerting the administrator as required.
7. Finally, additional undocumented Security features will exist between all layer transitions but as these features are my own bespoke design, their description is beyond the scope of this document. In short, I could tell you, but then I'd have to kill you.

Tiggs

Coming soon

This is the holding page for the UM PEAR experiment blog. Please check back in the next two weeks or so for an initial update.