Lines Matching full:and
12 the key ideas of the security process and outlines which documents need
13 to be created. After the process is implemented and all supporting
14 documents are created, this document is a top-level overview and entry
17 Overview and Scope
26 1. **Secure Development:** Defines the system architecture and
28 principles and quality assurance procedures.
30 2. **Secure Design:** Defines security procedures and implement measures
31 to enforce them. A security architecture of the system and
32 relevant sub-modules is created, threats are identified, and
33 countermeasures designed. Their correct implementation and the
36 and mitigating security issues.
39 Zephyr RTOS. This includes an evaluation target, its assets, and
41 determined and backed with appropriate evidence.
51 by the Zephyr Security Subcommittee and the Zephyr Technical Steering
53 (security) engineers and architects.
59 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
63 highly recommended requirements, and truly optional requirements. As
70 the benefit of the experience and discussion that produced the
76 This document is a living document. As new requirements, features, and
83 2. The Zephyr Security Subcommittee will review these changes and provide feedback
93 and code quality assurance, although additional security features are
99 algorithms and protocols. Support for cryptographic hardware is
101 monolithic binary and removes the need for dynamic loaders,
108 and guarantees stable APIs. Static code analyses provide additional
111 - **Execution Protection** including thread separation, stack and
114 protection and thread separation were added in version 1.10.0 for X86
115 and in version 1.11.0 for ARM and ARC.
123 cryptographic algorithms, and on its monolithic system design.
127 Crypto APIs, ensuring a standardized and secure approach to
132 APIs for vendor specific cryptographic IPs in both hardware and software
134 modules (SAMs), Trusted Platform Modules (TPMs), and
138 Zephyr kernel and all applications are compiled into a single static
146 features to split the system into privileged and unprivileged execution
148 partition system resources (memory, peripheral address space, etc.) and
150 thread execution level, and memory protection constraints are enforced
157 is to have a process including mandatory code reviews, feature and issue
158 management/tracking, and static code analyses.
160 Code reviews are documented and enforced using a voting system before
166 - Increasing the readability and maintainability of the contributed
169 - Ensuring appropriate usage of string and memory functions
175 The current coding principles focus mostly on coding styles and
176 conventions. Functional correctness is ensured by the build system and
178 concrete and detailed guidelines need to be developed and aligned with
184 Bug and issue tracking and management is performed using Github. The term
186 security issue categorization and management. A problem identified as
199 Execution protection is supported and can be categorized into the
202 - **Memory separation:** Memory will be partitioned into regions and
207 detecting and trapping stack overruns. Individual threads should
213 program flow protection and other measures for tamper resistance
235 Some of these categories are interconnected and rely on multiple pieces
242 include coding guidelines and development processes that can be roughly
243 separated into two categories related to software quality and related to
245 created and kept up-to-date with future development.
256 Services*) and a user-specific part (*Application Services*). The OS
257 part itself contains low-level, platform specific drivers and the
259 functions, and the cryptographic library.
261 A document describing the system architecture and design choices shall
262 be created and kept up to date with future development. This document
263 shall include the base architecture of the Zephyr OS and an overview of
265 document shall be created and evaluated against the implementation.
266 These documents shall serve as an entry point to new developers and as a
279 security violations and limit their impact:
284 security measures, publicly accepted cryptographic algorithms and
288 system shall be kept as simple and small as possible. In the
290 modular code [PAUL09]_ and abstracted APIs.
292 - **Complete mediation** requires that each access to every object and
297 and permitted only in specific conditions defined by the system
309 program and thread shall have the smallest possible
317 be implemented as a shared library executed by each user and not
321 easy to use by the developers in order to ensure its usage and
339 functionality and module shall be represented as a configuration
340 option and needs to be explicitly enabled. Then, all features,
341 protocols, and drivers not required for a particular use case can
342 be disabled. The user shall be notified if low-level options and
348 and validation phase. In each stage, appropriate documentation
353 Based on these design principles and commonly accepted best practices, a
354 secure development guide shall be developed, published, and implemented
364 naming schemes of modules, functions, variables, and so forth.
365 This increases the readability of the Zephyr code base and eases
370 consistent releases with a well-documented feature set and a
374 and shall be performed on each proposed code change prior to
377 These reviews shall be performed by the subsystem maintainers and
378 developers on a functional level and are to be distinguished from
388 Waivers shall be documented centrally and
390 documentation shall include the employed tool and its version,
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
394 main release branch and on the security branch. It shall be
401 process and metrics such as cyclomatic complexity shall be
405 - **Automation:** the review process and checks for coding rule
409 in from subsystems, in addition to review process and coding rule
410 adherence, all static code analysis must have been run and issues
413 Release and Lifecycle Management
419 operating system and/or security related sub-systems of Zephyr
422 - **Lifecycle management:** system stages shall be defined and
425 locking of the device in case an attack has been detected, and a
429 cycle, documenting releases, and maintaining a record of known
430 vulnerabilities and mitigations. Especially for certification
435 - **Rights management and NDAs:** if required by the chosen
436 certification, the confidentiality and integrity of the system
438 separate source code repository) and non-disclosure agreements
450 needs to be clearly defined and its application needs to be monitored
451 and driven. This process includes the development of security related
452 modules in all of its stages and the management of reported security
454 known and future attack vectors, and their impact on the system needs to
455 be investigated and mitigated. Please refer to the
462 avoid that individual components breach the system security and
469 preparation of each security-targeted release and each time a
473 security strategy and architecture, and the preparation of audits
477 system vulnerabilities and their mitigation as described in
480 These criteria and tasks need to be integrated into the development
481 process for secure software and shall be automated wherever possible. On
482 system level, and for each security related module of the secure branch
490 security design on system- and module-level. The high level
493 - The identification of **security and compliance requirements**
502 - Support for **Trusted Platform Modules (TPM)** and
508 - Task scheduler and separation
514 1. **Identification of assets** such as user data, authentication and
521 3. **Definition of requirements** regarding security and protection of
525 architecture and implementation to determine potential deviations and
530 considered and documented.
538 Threat Modeling and Mitigation
542 the development of an accurate security architecture and for most
545 these assets are protected by the system and which threats against them
547 model is created. This model contains the asset and system
550 it resides in, and the overall system is to be estimated. This threat
551 model is then considered in the module and system security architecture
552 and appropriate countermeasures are defined to mitigate the threat or
560 2. Application decomposition and creation of appropriate data flow
563 3. Threat identification and categorization using the [STRIDE09]_ and
566 4. Determination of countermeasures and other mitigation approaches
569 and before major changes of the module or system architecture.
572 security reviews, the threat models and the mitigation techniques shall
575 From these threat models and mitigation techniques tests shall be
585 investigations on cryptographic algorithms, critical OS tasks, and
592 configuration and hardware as one system.
596 invariance** of the cryptographic algorithms and modules is
598 software implementations and when using cryptographic hardware.
600 - **Fuzzing tests** shall be performed on both exposed APIs and
604 module and for the complete Zephyr system (in general on a particular
605 hardware platform), a suitable VA plan shall be created and executed.
607 management process, and learnings shall be formulated as guidelines and
618 scope and scheme are yet to be decided. However, many certifications such
622 certification scheme and evaluation level, this process needs to be
633 cryptographic keys, user data such as communication logs, and
636 2. Developing a **threat model** and **security architecture** to
646 evaluated and certified, as well as assumptions on the operating
657 and might include items not relevant for the certification.
667 platform and the final application running on top of Zephyr. If
668 these assumptions are met by the hardware and the application, a
681 including a specific hardware, the Zephyr RTOS, and an
686 (main-stream Zephyr, security branch, or certain modules), and the
689 In case of partial certifications (options 1 and 2), assumptions on
690 hardware and/or software are required for certifications. These can
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
702 - The device and its software stack is configured and operated by
703 **properly trained and trusted individuals** with no malicious
706 These assumptions shall be part of the security claim and evaluation