Looking at safety with our security glasses on


Separation of privilege and the avoidance of unpleasant surprises

Another post in an occasional series on how Saltzer and Schroeder’s eight principles of security and safety engineering seem to overlap in a number of areas, and what we might get from looking at safety with from a security perspective. In this post I’ll look at the concept of separation of privilege.

Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key… The reason is that, once the mechanism is locked, the two keys can be physically separated and distinct programs, organizations, or individuals made responsible for them. From then on, no single accident, deception, or breach of trust is sufficient to compromise the protected information. This principle is often used in bank safe-deposit boxes. It is also at work in the defense system that fires a nuclear weapon only if two different people both give the correct command…

Saltzer & Schroeder

So if we’re designing a safety system access to critical functions should require two independent and therefore necessarily dissimilar ‘key’ inputs. As Saltzer and Schroeder point out once this is implemented no single failure can compromise the system. Thus as a design objective a command input to a safety critical function should also be accompanied by a consent input, both being required before the recipient function will act, importantly both command and consent should also be ‘keyed’, that is they should allow the recipient function to unambiguously identify that the input has come from a valid independent authority.

An examples illustrates the principle, the CAN open safety protocol DSP 304 uses serial redundancy where safety critical data (and commands) are transmitted in two independent messages with the data in the second message bit-wise inverted and cross-checked after re-inversion with the first message in the receiver. However, as DSP 304 invokes no requirements for independence of these messages they cannot be said to satisfy the independence element of the separation of privileges, and could potentially have been generated by a single software fault in the functional chain. On the other hand if the message pair were also interlocked with an independent unique hardware consent signal, and the messages would be discarded by the receiver in the absence of a consent signal, then we could say that we were complying with the principle of separation of privilege.

The separation of privilege strategy can be seen as an implementation that satisfies a higher level safety goal of incompatibility in that is our intent in employing it to ensure that enabling stimuli for safety critical functions are sufficiently unique (through redundancy and dissimilarity) that they can’t be duplicated by the environment.