Secure Software Concepts

Authorization
Authorization determines whether a particular person or process is authorized to perform
a given activity.
Authorization can be determined based on a range of restrictions, for example, the
users groups and roles in the organization, the access time, the IP address of the
request origin, etc.
Examples of authorization: the Windows or Unix OS granting read/write access to a
specific file for logged-in users, the corporate employee portal site granting access to an
employees salary information based on the requesters role in the company, etc.
The combination of authentication and authorization is called access control.

Discretionary Access Control

In discretionary access control (DAC), the owner of the object specifies which subjects
can access the object. This model is called discretionary because the control of access
is based on the discretion of the owner.
Most operating systems such as all Windows, Linux, and Macintosh and most flavors of
Unix are based on DAC models.
In these operating systems, when you create a file, you decide what access privileges
you want to give to other users; when they access your file, the operating system will
make the access control decision based on the access privileges you created.
WiKi - In computer security, discretionary access control (DAC) is a type of access
control defined by the Trusted Computer System Evaluation Criteria "as a means of
restricting access to objects based on the identity of subjects and/or groups to which
they belong. The controls are discretionary in the sense that a subject with a certain
access permission is capable of passing that permission (perhaps indirectly) on to any
other subject (unless restrained by mandatory access control)".
\
Mandatory Access Control

In mandatory access control (MAC), the system (and not the users) specifies which
subjects can access specific data objects.
The MAC model is based on security labels. Subjects are given a security clearance
(secret, top secret, confidential, etc.), and data objects are given a security classification
(secret, top secret, confidential, etc.). The clearance and classification data are stored in
the security labels, which are bound to the specific subjects and objects.
When the system is making an access control decision, it tries to match the clearance
of the subject with the classification of the object. For example, if a user has a security
clearance of secret, and he requests a data object with a security classification of top
secret, then the user will be denied access because his clearance is lower than the
classification of the object.

The MAC model is usually used in environments where confidentiality is of utmost
importance, such as a military institution.
Examples of the MAC-based commercial systems are SE Linux and Trusted Solaris.

Secure boot
A secure boot scheme adds cryptographic checks to each stage of the Secure world
boot process. This process aims to assert the integrity of all of the Secure world software
images that are executed, preventing any unauthorized or maliciously modified software
from running.
Cryptographic signature protocol
The most logical cryptographic protocol to apply is one based on a public-key signature
algorithm, such as RSA-PSS (Rivest, Shamir and Adleman - Probabilistic Signature
Scheme).
In these protocols a trusted vendor uses their Private Key (PrK) to generate a signature
of the code that they want to deploy, and pushes this to the device alongside the
software binary. The device contains the Public Key (PuK) of the vendor, which can be
used to verify that the binary has not been modified and that it was provided by the
trusted vendor in question.
The PuK does not need to be kept confidential, but it does need to be stored within the
device in a manner which means it cannot be replaced by a PuK that belongs to an
attacker.
Chain of trust
The secure boot process implements a chain of trust. Starting with an implicitly trusted
component, every other component can be authenticated before being executed. The
ownership of the chain can change at each stage - a PuK belonging to the device OEM
might be used to authenticate the first bootloader, but the Secure world OS binary might
include a secondary PuK that is used to authenticate the applications that it loads.
Unless a design can discount hardware shack attacks the foundations of the secure boot
process, known as the root of trust, must be located in the on-SoC ROM. The SoC ROM
is the only component in the system that cannot be trivially modified or replaced by
simple reprogramming attacks.
Storage of the PuK for the root of trust can be problematic; embedding it in the on-SoC
ROM implies that all devices use the same PuK. This makes them vulnerable to class-
break attacks if the PrK is stolen or successfully reverse-engineered. On-SoC One-
Time-Programmable (OTP) hardware, such as poly-silicon fuses, can be used to store
unique values in each SoC during device manufacture. This enables a number of
different PuK values to be stored in a single class of devices, reducing risk of class
break attacks.
Note
OTP memory can consume considerable silicon area, so the number of bits are that
available is typically limited. A RSA PuK is over 1024-bits long, which is typically too
large to fit in the available OTP storage. However, as the PuK is not confidential it can
be stored in off-SoC storage, provided that a cryptographic hash of the PuK is stored on-
SoC in the OTP. The hash is much smaller than the PuK itself (256-bits for a SHA256
hash), and can be used to authenticate the value of the PuK at run-time.
On-SoC Secure world or Off-SoC Secure world
The simplest defense against shack attacks is to keep any Secure world resource
execution located in on-SoC memory locations. If the code and data is never exposed
outside of the SoC package it becomes significantly more difficult to snoop or modify
data values; a physical attack on the SoC package is much harder than connecting a
logic probe to a PCB track or a package pin.
The secure boot code is generally responsible for loading code into the on-SoC memory,
and it is critical to correctly order the authentication to avoid introducing a window of
opportunity for an attacker. Assuming the running code and required cryptographic
hashes are already in safe on-SoC memory, the binary or PuK being verified should be
copied to a secure location before being authenticated using cryptographic methods. A
design that authenticates an image, and then copies it into the safe memory location
risks attack. The attacker can modify the image in the short window between the check
completing and the copy taking place.