Lines Matching +full:resistance +full:- +full:based
1 .. _security-overview:
14 documents are created, this document is a top-level overview and entry
32 relevant sub-modules is created, threats are identified, and
43 .. figure:: media/security-process-steps.png
64 noted in RFC-2119, "These terms are frequently used to specify behavior
98 - **Security** **Functionality** with a focus on cryptographic
104 - **Quality Assurance** is driven by using a development process that
111 - **Execution Protection** including thread separation, stack and
137 The security architecture is based on a monolithic design where the
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
173 - Reviewing the security relevant code for potential issues
185 "survivability" was coined to cover pro-active security tasks such as
190 they are closed as non-issues (at least another person educated in
191 security processes need to agree on non-issue before closing).
202 - **Memory separation:** Memory will be partitioned into regions and
203 assigned attributes based on the owner of that region of memory.
206 - **Stack protection:** Stack guards would provide mechanisms for
210 - **Thread separation:** Individual threads should only have access to
213 program flow protection and other measures for tamper resistance
222 - Secure/trusted boot
223 - Over the air (OTA) updates
224 - External Communication
225 - Device authentication
226 - Access control of onboard resources
228 - Flash updating
229 - Secure storage
230 - Peripherals
232 - Root of trust
233 - Reduction of attack surface
245 created and kept up-to-date with future development.
250 .. figure:: media/security-zephyr-system-architecture.png
254 A high-level schematic of the Zephyr system architecture is given in
256 Services*) and a user-specific part (*Application Services*). The OS
257 part itself contains low-level, platform specific drivers and the
258 generic implementation of I/O APIs, file systems, kernel-specific
281 - **Open design** as a design principle incorporates the maxim that
283 widespread use. Instead of relying on secret, custom-tailored
287 - **Economy of mechanism** specifies that the underlying design of a
292 - **Complete mediation** requires that each access to every object and
296 - **Fail-safe defaults** defines that access is restricted by default
303 - **Separation of privilege** is the principle that two conditions or
308 - **Least privilege** describes an access model in which each user,
314 - **Least common mechanism** specifies that mechanisms common to more
320 - **Psychological acceptability** requires that security features are
327 - **Complementary Security/Defense in Depth:** do not rely on a single
334 - **Less commonly used services off by default**: to reduce the
342 be disabled. The user shall be notified if low-level options and
345 - **Change management:** to guarantee a traceability of changes to the
353 Based on these design principles and commonly accepted best practices, a
363 - **Adherence to the Coding Conventions** with respect to coding style,
367 automated scripts prior to check-in.
369 - **Adherence to Deployment Guidelines** is required to ensure
370 consistent releases with a well-documented feature set and a
373 - **Code Reviews** ensure the functional correctness of the code base
375 check-in. Code reviews shall be performed by at least one
382 - **Static Code Analysis** tools efficiently detect common coding
387 waive potential false-positives before each release.
400 - **Complexity Analyses** shall be performed as part of the development
405 - **Automation:** the review process and checks for coding rule
418 - **Device management** encompasses the possibility to update the
419 operating system and/or security related sub-systems of Zephyr
422 - **Lifecycle management:** system stages shall be defined and
428 - **Release management** describes the process of defining the release
435 - **Rights management and NDAs:** if required by the chosen
438 separate source code repository) and non-disclosure agreements
461 - **Adherence to the Secure Development Coding** is mandatory to
466 as countermeasures manually in security-critical modules.
468 - **Security Reviews** shall be performed by a security architect in
469 preparation of each security-targeted release and each time a
470 security-related module of the Zephyr project is changed. This
476 - **Security Issue Management** encompasses the evaluation of potential
490 security design on system- and module-level. The high level
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**
502 - Support for **Trusted Platform Modules (TPM)** and
505 - Mechanisms to allow for **in-the-field** **updates** of devices using
508 - Task scheduler and separation
510 The security architecture development is based on assets derived from
511 the structural overview of the overall system architecture. Based on
526 mitigate existing weaknesses. Newly developed sub-modules that are
590 - **Penetration testing** of the RTOS on a particular hardware
594 - **Side channel attacks** (timing invariance, power invariance, etc.)
600 - **Fuzzing tests** shall be performed on both exposed APIs and
621 outlined in the following. Based on the final choices for the
641 which the vendor could use to certify their Zephyr-enabled
684 In all three cases, the certification scheme (e.g., FIPS 140-2 [NIST02]_
686 (main-stream Zephyr, security branch, or certain modules), and the
693 - **Appropriate physical security** of the hardware platform and its
696 - **Sufficient protection of storage and timing channels** on
700 - Only **trusted/assured applications** running on the device
702 - The device and its software stack is configured and operated by