Security Policy
Last updated
Last updated
This example demonstrates how to specify a system specification.
We consider a smart card that we want to certify at EAL5+ level. It is necessary to model the security policy and to verify by proof that it is consistent.
We define:
the objects implemented in the security policy and
the expected security properties,
in terms of access rights to the various memories according to the type of process executing a given operation.
Representing the operation of the CPU, MPU memory system
Focused on memory access management
process mode USER or SUPERVISOR tMODE
memory type RAM, PUBLIC ROM or SECURE ROM tMEMORY
memory content DATA or CODE tCONTENT
operation READ, WRITE or EXECUTE tOPERATION
access GRANTED or NOT GRANTED tRESULT
Each time an attempt is made to perform an operation to a memory slot for a process mode, then the access is:
either allowed (GRANTED) or
not yet allowed (NOT GRANTED)
The memory is abstract (we do not manipulate addresses but memory cells): abstract set MEMORY.
Indication functions allow to associate to each memory cell
Its type (memory map): MEMORY_TYPE : MEMORY --> tMEMORY
Its content: MEMORY_CONTENT : MEMORY --> tCONTENT
Four variables are defined:
currentCell currentCell : MEMORY
currentOperation currentOperation : tOPERATION
currentMode currentMode : tMODE
currentResult currentResult : tRESULT
Properties are permanently checked by these four variables.
Below is the skeleton of the B machine politique.mch:
This specification needs to be completed with more operations and invariants. One operation and one invariant are given below.
If the current memory location is RAM, the memory cell contains CODE, and the current operation is EXECUTE, then access is granted.
A memory cell of type ROM_SECURE can only be read in SUPERVISOR mode.
: