The document introduces the secure boot pattern, which addresses ensuring the integrity of the software stack loaded on a platform. The pattern uses a chain of trust where each boot stage verifies the integrity of the next stage using cryptographic methods. The root of trust is a first module protected by hardware that verifies the initial integrity. The pattern provides security benefits while introducing complexity and overhead. Variants include authenticated boot, which detects instead of preventing integrity violations.

1. Dr.-Ing. Marcel Winandy
Security Patterns
An Introduction

2. Why Patterns?
Patterns help to address these objectives:
• Documentation of successful solutions for repeating problems
• Creation of a common „language“
It’s not about technology, it’s about a culture of documentation
of good architectures and designs.

3. What is a Pattern?
• A (design) pattern is a description or template for how to solve a problem
that can be used in many different situations.
• „The pattern describes a problem which again and again occurs in the work,
as well as the principle of its solution, in a way that the solution can be used
repeatedly without changes.“ (Christopher Alexander, architect)
• An organized collection of patterns that relate to a particular
fi
eld is called a
pattern language.

4. What is not a Pattern?
• NOT: „A pattern is a solution to a problem in a context.“
• Counter example:
‣ Problem: How to allocate objects in memory?
‣ Context: object-oriented programming system in a computer with virtual memory.
‣ Solution: Run some typical applications to
fi
gure out which objects need to
communicate. Place those objects on the same virtual page.
• This is not a pattern! This is just a solution for a problem in a context.
• What is missing: abstraction of solution principle to make it applicable in similar contexts

5. Types of Patterns
• Architectural Patterns
• Analysis Patterns
• Design Patterns
• Coding Patterns (Ideoms)
• Organizational Patterns
• Anti-Patterns
• Security Patterns

6. What can we achieve with Security Patterns?
Security Pattern Language
• Common understanding
of concepts
• Navigate through
dependencies
• Identify capability for reuse
of security building blocks
or services
• Common language among
architects, designers,
developers, etc.

7. What can we achieve with Security Patterns?
Security Pattern Catalogs
• Derive architectural structures
• Tailored for speci
fi
c applications,
use case domains, businesses
• Avoid repetition of work
• Avoid misunderstandings (through
use of common language)
• Consistent quality
• Faster development
Core Security Patterns Catalog
Security Patterns for J2EE Applications

8. Key Elements of a Pattern
Problem
Context
Solution
Example
Example Resolved
Name
Intent
Related Patterns
Consequences
Known Uses
Variants

9. Patterns for Secure Boot and Secure Storage in Computer Systems
Hans Löhr, Ahmad-Reza Sadeghi, Marcel Winandy
Horst Görtz Institute for IT Security, Ruhr-University Bochum, Germany
{hans.loehr,ahmad.sadeghi,marcel.winandy}@trust.rub.de
Abstract—Trusted Computing aims at enhancing the security
of IT systems by using a combination of trusted hardware
and software components to provide security guarantees. This
includes system state integrity and the secure link between
the software and hardware of a computing platform. Although
security patterns exist for operating system security, access
control, and authentication, there is still none of Trusted
Computing aspects. In this paper, we introduce security
patterns for secure boot and for secure storage, which are
important basic Trusted Computing concepts. Secure boot is
at the heart of most security solutions and secure storage is
fundamental for application-level security: it ensures that the
integrity of software is verified before accessing stored data.
Our paper aims at complementing existing system security
patterns by presenting the common patterns underlying the
different realizations of secure boot and secure storage.
Keywords-security patterns; trusted computing; secure boot;
secure storage;
I. INTRODUCTION
The literature on security patterns includes numerous
patterns related to operating systems, e.g., concerning au-
thentication and access control. However, until now, Trusted
Computing (TC) has received very little attention from
the pattern community. TC aims to employ a combination
of hardware security mechanisms and software to address
security problems that cannot be solved by software alone.
Particularly relevant among these are security threats related
to malicious software, such as Trojan horses and viruses.
By now, there is not only a tremendous amount of research
in this field, but TC concepts can also be found in a wide
variety of products, ranging from embedded devices, such as
mobile phones, to servers equipped with expensive tamper-
resistant secure co-processors. The best-known approach to
TC is based on the specifications released by the Trusted
Computing Group (TCG) [1].
In this paper, we present the patterns underlying two
fundamental TC concepts: secure boot and secure storage.
Secure boot guarantees that violations of integrity prop-
erties of the software stack that is booted on a platform
can be prevented, i.e., software that violates the integrity
properties cannot be loaded. A variant of this pattern, termed
authenticated boot, does not prevent software from being
loaded, but allows reliable verification of the load-time
integrity of the software that has been booted later on. Secure
boot is a building block at the heart of many TC-based
solutions (including implementations of secure storage).
Secure storage is a crucial application-level requirement
in many scenarios. Simple encryption is often not enough to
protect sensitive data: it must also be ensured that an attacker
cannot obtain the decryption key. Secure storage solves this
issue by using hardware (and software) to enforce access
restrictions on the stored data. Before access is granted to
an application, the integrity of the software is verified.
Secure storage and secure boot are essential concepts for
TC systems. For instance, a Common Criteria protection
profile for security kernels with TC support has been eval-
uated and certified recently [2], which also includes secure
boot and secure storage. The security patterns described here
could be helpful to implement these features for security
kernels that aim to comply with this protection profile.
This paper describes the common pattern underlying
various existing realizations of secure boot [3], [4], [1], [5],
and of secure storage [4], [1], [5].
II. SECURE BOOT PATTERN
Intent: This pattern addresses how to ensure that vio-
lations of integrity properties of the software stack that is
booted on a platform can be either prevented (secure boot)
or detected (authenticated boot).
A. Example
Consider a user who wants to use a computing device
that was left unattended or that was used by another person
before. How can the user be sure that the system software
is in the intended operational state, i.e., that no critical
component of the operating system or other software ap-
plications has been modified in a malicious or unauthorized
way? Typically, a file integrity checker program can check
the integrity of system and application files. However, any
file integrity checker program must rely on trusted reference
values and that those values have not been tampered with.
Moreover, the user wants also to be sure that the file integrity
checker itself is not tampered with or deactivated at all.
B. Context
Users of security-sensitive applications want to be sure
about the operational integrity of their applications and exe-
cution environment. Unauthorized changes to the application
code or the operating system may lead to unintentional
program behavior or violation of security goals. Users trust
the hardware, but they need a way to verify that the software
loaded on this hardware has not been tampered with.
Example
Secure Boot Pattern

10. Secure Boot Pattern
Intent:
This pattern addresses how to ensure that violations of integrity properties of the
software stack that is booted on a platform can be either prevented (secure boot) or
detected (authenticated boot).

11. Example
• Password wallet for web authentication
RuhR-University Bochum System Security Lab
Motivating Example
● Password wallet for web authentication
passwords
Client PC
Web Server
How do you know that your trusted
system has started?

12. Context
• Users want to be sure about operational integrity of applications and OS
• Unauthorized changes may lead to security violation
• Users trust the hardware
- But need to verify integrity status of loaded software
• Users can be local or remote

13. Problem
• Software can be manipulated or exchanged
• Malware can register itself within any stage of the boot process
• Forces:
- You want to ensure integrity of loaded software
- You want the computer to always boot in a well-de
fi
ned secure state
- You want to allow modi
fi
cations of the system (e.g. updates, additional software)

14. Solution
• Chain of trust
- Each boot stage veri
fi
es integrity of next stage
- using cryptographically secure methods (hash functions, digital signature)
- Only if check is ok, control is transferred to next stage; otherwise: system is halted
• Root of trust
- Whole process depends on integrity of
fi
rst module
- First module therefore protected by hardware
- Including the integrity veri
fi
cation data (hash, keys)

15. Solution
• Structure:
RuhR-University Bochum System Security Lab
Solution
● Structure:

16. Solution
• Dynamics:
Root of Trust Bootloader Module 1 Module 2 Module n
…
Integrity Problem?
Halt System

17. Example Resolved
• Password wallet for web authentication
RuhR-University Bochum System Security Lab
Motivating Example
● Password wallet for web authentication
passwords
Client PC
Web Server
How do you know that your trusted
system has started?
Secure Boot

18. Variants
• Authenticated Boot
- Does not halt if integrity veri
fi
cation fails
- But allows (remote) party to verify the system state
- Integrity measurement results are recorded securely for later inspection(e.g. in
protected hardware registers)
- Trusted (hardware) module vouches for stored results (e.g. via digital signature)

19. Consequences
• Bene
fi
ts:
- Software integrity state is veri
fi
ed at boot time
- System starts only if integrity is OK
- Authenticated boot: more
fl
exible, check later
• Liabilities:
- Setup/update of integrity veri
fi
cation data securely
- Speci
fi
c mechanisms needed for software updates
- Integrity checks are only load-time, not runtime
- Adds complexity and overhead

20. Known Uses
RuhR-University Bochum System Security Lab
Known Uses
● Cell BE processor
● Trusted Platform Module (TPM)
● Open Mobile Terminal Platform (OMTP) specs
Sony PlayStation3
PCs, Laptops
Mobile phones
(Authenticated Boot)
(Abstract definition, different implementations)

21. Related Patterns
• Boot Loader: describes the boot process as a sequence of single bootstrap
stages.
• Authenticator: veri
fi
es the identity of a subject and creates a proof of
identity for later use, e.g., in access control decisions.

22. Secure Boot Pattern
Problem
Context
Solution
Example
Example Resolved
Name: Secure Boot
Intent
Related Patterns
Consequences
Known Uses
Variants

23. Conclusion
• Tremendous literature and resources available on Security Patterns
• Common language and understanding by Security Pattern Languages
• Reusable architectural structures tailored for speci
fi
c business applications
via Security Pattern Catalogs
• More consistent, quality-focused, and faster development achievable
• Example given: Secure Boot Pattern