Lines Matching refs:of
9 This document outlines the steps of the Zephyr Security Subcommittee towards a
12 the key ideas of the security process and outlines which documents need
20 We begin with an overview of the Zephyr development process, which
23 In subsequent sections, the individual parts of the process are treated
31 to enforce them. A security architecture of the system and
34 validity of the threat models are checked by code reviews.
38 3. **Security Certification:** Defines the certifiable part of the
50 This document is a guideline for the development of a security process
52 Committee. It provides an overview of the Zephyr security process for
65 with security implications. The effects on security of not implementing
68 time to elaborate the security implications of not following
70 the benefit of the experience and discussion that produced the
84 or acceptance of the changes.
86 3. Once accepted, these changes will become part of the document.
91 This section recapitulates the current status of secure development
106 common repository. Furthermore, the reuse of proven building
122 The security functionality in Zephyr hinges mainly on the inclusion of
128 cryptographic operations. mbedTLS, as the implementation of PSA
129 Crypto, supports a wide range of cryptographic algorithms, making it
133 are planned, including secure key storage in the form of secure access
145 In addition, applications can take advantage of thread separation
149 assign resources to individual threads or groups of threads. Stack,
151 at the time of context switch.
162 maintainer. The main goals of the code review are:
164 - Verifying correct functionality of the implementation
166 - Increasing the readability and maintainability of the contributed
169 - Ensuring appropriate usage of string and memory functions
171 - Validation of the user input
177 the experience of the reviewer. Especially for security relevant code,
194 more detail; this document is part of that process.
203 assigned attributes based on the owner of that region of memory.
219 System level security encompasses a wide variety of categories. Some
220 examples of these would be:
226 - Access control of onboard resources
232 - Root of trust
233 - Reduction of attack surface
235 Some of these categories are interconnected and rely on multiple pieces
241 The development of secure code shall adhere to certain criteria. These
254 A high-level schematic of the Zephyr system architecture is given in
258 generic implementation of I/O APIs, file systems, kernel-specific
263 shall include the base architecture of the Zephyr OS and an overview of
264 important submodules. For each of the modules, a dedicated architecture
275 adhering to a defined set of design standards. These standards are
283 widespread use. Instead of relying on secret, custom-tailored
287 - **Economy of mechanism** specifies that the underlying design of a
289 context of the Zephyr project, this can be realized, e.g., by
303 - **Separation of privilege** is the principle that two conditions or
305 context of the Zephyr project, this could encompass split keys
310 subset of permissions in the system required to perform their
312 surface of the system.
322 the correctness of its application.
325 specific to the development of a secure RTOS:
328 threat mitigation approach. In case of the complementary security
329 approach, parts of the threat mitigation are performed by the
335 exposure of the system to potential attacks, features or services
337 threshold of 80% is given in [MS12]_). For the Zephyr project,
345 - **Change management:** to guarantee a traceability of changes to the
364 naming schemes of modules, functions, variables, and so forth.
365 This increases the readability of the Zephyr code base and eases
371 trackable list of security issues.
373 - **Code Reviews** ensure the functional correctness of the code base
376 independent reviewer other than the author(s) of the code change.
389 in the form of a comment inside the source code itself. The
391 the date of the analysis, the branch and parent revision number,
392 the reason for the waiver, the author of the respective code, and
393 the approver(s) of the waiver. This shall as a minimum run on the
400 - **Complexity Analyses** shall be performed as part of the development
406 adherence are a mandatory part of the precommit checks. To
407 ensure consistent application, they shall be automated as part of
408 the precommit procedure. Prior to merging large pieces of code
419 operating system and/or security related sub-systems of Zephyr
425 locking of the device in case an attack has been detected, and a
426 termination if the end of life is reached.
428 - **Release management** describes the process of defining the release
429 cycle, documenting releases, and maintaining a record of known
431 purposes the integrity of the release needs to be ensured in a
432 way that later manipulation (e.g., inserting of backdoors, etc.)
436 certification, the confidentiality and integrity of the system
439 between the relevant parties. In case of a repository shared
451 and driven. This process includes the development of security related
452 modules in all of its stages and the management of reported security
463 to minimize the vulnerability of individual modules. While this
465 investigate the correct implementation of security features such
469 preparation of each security-targeted release and each time a
470 security-related module of the Zephyr project is changed. This
471 process includes the validation of the effectiveness of
473 security strategy and architecture, and the preparation of audits
476 - **Security Issue Management** encompasses the evaluation of potential
482 system level, and for each security related module of the secure branch
483 of Zephyr, a directly responsible security architect shall be defined to
493 - The identification of **security and compliance requirements**
495 - **Functional security** such as the use of cryptographic functions
498 - Design of **countermeasures** against known attack vectors
500 - Recording of security relevant **auditable events**
505 - Mechanisms to allow for **in-the-field** **updates** of devices using
511 the structural overview of the overall system architecture. Based on
514 1. **Identification of assets** such as user data, authentication and
518 2. **Identification of threats** against the assets such as breaches of
519 confidentiality, manipulation of user data, etc.
521 3. **Definition of requirements** regarding security and protection of
527 integrated into the secure branch of the Zephyr project shall provide
541 The modeling of security threats against the Zephyr RTOS is required for
542 the development of an accurate security architecture and for most
543 certification schemes. The first step of this process is the definition
544 of assets to be protected by the system. The next step then models how
548 vulnerabilities, as well as the description of the potential exploits of
553 limit the impact of exploits.
558 1. Definition of assets
560 2. Application decomposition and creation of appropriate data flow
566 4. Determination of countermeasures and other mitigation approaches
568 This procedure shall be carried out during the design phase of modules
569 and before major changes of the module or system architecture.
576 derived that prove the effectiveness of the countermeasures. These tests
590 - **Penetration testing** of the RTOS on a particular hardware
596 invariance** of the cryptographic algorithms and modules is
606 The findings of these analyses shall be considered in the security issue
610 If possible (as in case of fuzzing analyses), these tests shall be
616 One goal of creating a secure branch of the Zephyr RTOS is to create a
631 1. The **definition of assets** to be protected within the Zephyr RTOS.
634 potentially IP of the vendor or manufacturer.
637 protect the assets against exploits of vulnerabilities of the
640 split model containing a precertified secure branch of Zephyr
645 **certification claims** on the security of the assets to be
650 consistent documentation of the security development process,
665 1. **Abstract precertification of Zephyr as a pure software system:**
667 platform and the final application running on top of Zephyr. If
673 2. **Certification of Zephyr on specific hardware platform without a
675 enablement of a secure platform running the Zephyr RTOS. The
680 3. **Certification of an actual product:** in this case, a full product
685 or Common Criteria [CCITSE12]_), the scope of the certification
689 In case of partial certifications (options 1 and 2), assumptions on
693 - **Appropriate physical security** of the hardware platform and its
696 - **Sufficient protection of storage and timing channels** on
697 the hardware platform itself and all connected devices. (No mentioning of
706 These assumptions shall be part of the security claim and evaluation