TABLE OF CONTENTS Security-related functions that handle sensitive data pervade the architecture, which implies that security needs to be considered in every aspect of the design and must be designed in from the start (it's very difficult to bolt on security afterwards). The standard reference on the topic [1] recommends that a security architecture have the properties listed below, with annotations explaining the approach towards meeting them used in cryptlib:
Permission-based access: The default access/use permissions should be deny-all, with access or usage rights being made selectively available as required. Objects are only visible to the process that created them, although the default object-access setting makes it available to every thread in the process. This arises from the requirement for ease of use having to explicitly hand an object off to another thread within the process would significantly reduce the ease of use of the architecture. For this reason, the deny-all access is made configurable by the user, with the option of making an object available throughout the process or only to one thread when it is created. If the user specifies this behaviour when the object is created, then only the creating thread can see the object unless it explicitly hands off control to another thread.
Least privilege and isolation: Each object should operate with the least privileges possible to minimise damage due to inadvertent behaviour or malicious attack, and objects should be kept logically separate in order to reduce inadvertent or deliberate compromise of the...
