Best Practices for Embedded Application Security – OWASP

Click the blue text above Tansilab

Get more automotive cybersecurity news

System hardening, disabling unsafe functions, stack protection, and other protective measures have been repeated many times, but how to implement them remains unclear. Based on this, Qingji has organized OWASP’s “Embedded Application Security Best Practices,” a protective guide co-authored by developers, engineers, and enthusiasts. It unveils the mysteries of embedded application security practices from multiple angles including stack protection, injection protection, firmware upgrades and cryptographic signatures, secure storage of sensitive information, identity management, strengthening embedded frameworks and toolchains, debugging code and debugging interface usage, TLS security, data collection and storage usage/privacy, third-party code and components, threat modeling, etc. To present the core content without being bogged down by lengthy code, the following content has been abridged from the original. If interested, you can refer to the original text.1. Stack and Heap Overflow Protection

Prevent the use of known dangerous functions and APIs to avoid memory corruption vulnerabilities in firmware. (For example, avoid unsafeC functions such as-strcat,strcpy,sprintf,scanf. Memory corruption vulnerabilities such as buffer overflows may include stack overflows (stack overflow) or heap overflows (heap overflow). For simplicity, this document does not distinguish between these two types of vulnerabilities. If an attacker detects a buffer overflow and exploits it, the instruction pointer register will be overwritten to execute arbitrary malicious code provided by the attacker.

Search for vulnerableC functions in the source code. Example: Use the belowfind command in the “C” repository to find vulnerableC functions such as “strncpy” and “strlen“.

find . -type f -name ‘*.c’ -print0|xargs -0 grep -e ‘strncpy.*strlen’|wc –l

The grep expression can be used with the following expression

$ grep -E ‘(strcpy|strcat|strncat|sprintf|strlen|memcpy|fopen|gets)’ fuzzgoat.c

The following shows an example output of runningbugfinder onC source code.

$ flawfinder fuzzgoat.c // A static scanning tool

FINAL RESULTS:

fuzzgoat.c:1049: [4] (buffer) strcpy:

Does not check for buffer overflows when copying to destination (CWE-120).

Consider using strcpy_s, strncpy, or strlcpy (warning, strncpy is easily

misused).

fuzzgoat.c:368: [2] (buffer) memcpy:

Does not check for buffer overflows when copying to destination (CWE-120).

Make sure destination can always hold the source data.

…

Noncompliant Code Example: This non-compliant code example assumesget() can read no more thanBUFSIZ-1 characters fromstdin. This is an invalid assumption, and the resulting operation may lead to buffer overflow. Note thatBUFSIZ is a macro integer constant defined instdio.h, representing the recommended parameter forsetvbuf(), not the maximum size for such input buffers.

gets() function reads characters from standard input into the target array until it encounters the end of the file or reads a newline. It removes any newline characters and immediately writes a null character after the last character read into the array.

Compliant Example::fgets() function reads up to a specified number of characters from the stream into the array. This solution is compliant because the number of bytes copied fromstdin tobuf cannot exceed the allocated memory:

strncat() is a variant of the originalstrcat() library function. Both are used to append a null-terminatedC string to another string. The danger of the originalstrcat() is that the data provided by the caller may exceed the capacity of the receiving buffer, thus causing it to go out of bounds. The most common result issegmentation violation. Worse, anything behind the receiving buffer in memory gets silently and undetected corrupted.

strncat() adds an additional parameter allowing the user to specify the maximum number of bytes to copy. This is not the amount of data to copy. It is not the size of the source data. This is a limit on the amount of data to copy, typically set to the size of the receiving buffer.

“strncat” compliant example usage:

“strncat” non-compliant example usage:

The following screenshot demonstrates that stack protection support is enabled when building firmware images usingbuildroot.

Considerations When Programming

• What kind of buffers and their residing locations: physical, logical, virtual memory?

• What data will be retained when buffers are released or left for LRU?

· What strategy will be adopted to ensure old buffers do not leak data (e.g., zeroing out buffers after use)?

• Initialize buffers to known values upon allocation.

• Consider the storage locations of variables: stack, static, or allocated structures.

• Dispose of and securely erase buffers (e.g., erase buffers from locations storing personally identifiable information (PII) before releasing them) when they are no longer needed.

• Explicitly initialize variables.

• Ensure that secure compiler flags or switches are used for each firmware build. (For example, for GCC -fPIE, -fstack-protector-all, -Wl, -z, noexecstack, -Wl, -z, noexecheap, etc. For more information, see the other references section.)

• Use secure equivalent functions for known vulnerable functions, such as (below is a non-exhaustive list):

· It is recommended to useC library safe string functions such asgets()->fgets(),strcpy()->strncpy(),strcat()->strncat(),sprintf()->snprintf();

· Use self-wrapped safe string functions;

· Use other safe library functions, such as Intel’ssafestringlib,https://github.com/intel/safestringlib which provides functions such asmemcmp_s(),memcpy_s(),memmove_s(),memset_s();

• SoCs and MCUs include Memory Management Units (MMUs), use MMUs to implement isolation of threads and processes to reduce the attack surface when memory vulnerabilities are exploited; SoCs and MCUs include Memory Protection Units (MPUs), use MPUs to enforce access rules for memory and independent processes, as well as enforce privilege rules. If no MMU or MPU is available, use known bit monitoring stacks to monitor the consumption of the stack by determining how many known bits are no longer contained in the stack.

• If using FreeRTOS operating systems, consider using hook functions to set “configCHECK_FOR_STACK_OVERFLOW” to “1” during development and testing phases, but remove it in production phases.

2. Injection Protection

Ensure that all untrusted data and user inputs are validated, sanitized, and/or encoded outputs to prevent unintended system execution. Various injection attacks exist within application security, such as operating system (OS) command injection, cross-site scripting (for example,JavaScript injection),SQL injection, and other attacks (e.g.,XPath injection). However, the most common injection attacks in embedded software are related toOS command injection.

The code above when executingany_cmd‘happy’;useradd’attacker’ actually performs the operation of:

This is becausesystem uses a fullshell interpreter, thus it is recommended to useexecve(). The exec function series does not use a fullshell interpreter, so it is less susceptible to command injection attacks.

If the specified filename does not contain (/), thenexeclp(),execvp(), and (non-standard)execvP() functions will replicate the actions of ashell program when searching for executable files. Therefore, these should only be used when thePATH environment variable is set to a safe value.

execl(),execle(),execv(), andexecve() functions do not perform pathname replacement.

Additionally, precautions should be taken to ensure that untrusted users cannot modify external executable files, for example, by ensuring that the executable is not writable by users. This compliant solution is clearly different from the previous non-compliant code example. Firstly, the input is merged into theargs array and passed as parameters toexecve(), thus eliminating concerns about buffer overflow or string truncation when forming command strings. Secondly, this compliant solution forks a new process before executing/usr/bin/any_cmd in the child process. Although this method is more complex than callingsystem(), the increased security is worth the extra effort.

Considerations When Programming

• Do not call shell command wrappers, such as but not limited to:

·PHP:system()exec(),passthru(),shell_exec()

·C:system()popen(),exec(),execl(),execle(),execv(),execve()

·C++:ShellExecute()

·Lua:os.execute()

·Perl:system(),exec()

·Python:os.system()subprocess.call()

• If possible, avoid using user data for operating system commands. If necessary, establish a mapping from numbers to command strings for user-driven strings that may be passed to the operating system.

• Use a whitelist of accepted commands through mapping to ensure that only expected parameter values are processed.

• Ensure that user data is encoded according to context when outputting characters (e.g., HTML, JavaScript, CSS, etc.)

• HTML entity encoding, output encoding as: <, output encoding as>

3. Firmware Upgrades and Cryptographic Signatures

Ensure strong update mechanisms at download, and utilize cryptographic signatures for firmware images when applicable to update features related to third-party software. The signing and verification process uses public key encryption, such asPGP signatures. In case the private key is leaked, the software developer must revoke the leaked key, and all previous firmware versions will need to be re-signed with a new key.

note: PGP, Pretty Good Privacy, is a public key encryption algorithm commonly used to encrypt and sign communication data. We can usePGP to verify that the software we downloaded from a website has not been tampered with. The software’s author will sign their software usingPGP software, so you can verify the integrity of the software after downloading. SincePGP is asymmetric encryption, the author signs the software with their private key, thus we need to obtain the author’s public key, which is usually provided directly by the website, and then check the fingerprint of this public key to ensure it is the correct public key, then import the correct public key into thePGP keyring, then download the signature file of the software, and use the public key to verify the signature of the software. If the signature is correct, then the software has not been tampered with.

Below is an example of signing a kernel image:

(1) Download the image and the signature file of the image

wget [https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.xz] (https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.xz)

wget [https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.sign] (https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.sign)

(2) Download thePGP public key

# gpg2 –keyserver hkp://keys.gnupg.net –recv-keys 38DBBDC86092693E

gpg: /root/.gnupg/trustdb.gpg: trustdb created

gpg: key 38DBBDC86092693E: public key “Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>” imported

gpg: no ultimately trusted keys found

gpg: Total number processed: 1

gpg: imported: 1

(3) Unpack and verify the image

# xz -cd linux-4.6.6.tar.xz | gpg2 –verify linux-4.6.6.tar.sign –

gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT

gpg: using RSA key 38DBBDC86092693E

gpg: Good signature from “Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>” [unknown]

gpg: WARNING: This key is not certified with a trusted signature!

gpg: There is no indication that the signature belongs to the owner.

Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

(4) Handling warnings: We need to determine that the signature belongs to theowner, with the following methods:

• Use the Kernel.org trust network. This will require you to first find a member of kernel.org in your area and sign their key. Lacking a face-to-face meeting with the actual owner of the PGP key, this is the best option for validating the validity of the PGP key signature.

• Use gpg –list-sigs to view the list of signatures on the developer’s key. Email as many signed keys as possible, preferably from different organizations (or at least from different domains). Ask them to confirm they have signed the relevant key. You should give marginal trust to the replies received in this way (if any).

• Use the following site to view the trust path from Linus Torvalds’ key to the key used to sign the compressed package: pgp.cs.uu.nl. Enter Linus’s key in the “from” field, and the key you obtained in the output above in the “to” field. Generally, only Linus or someone with a direct signature from Linus is responsible for releasing the kernel.

(5) Handling “bad signature: Determine the tar being verified is not thetar.zx file, ensure that the downloaded file is correct and not truncated; sometimes we also encounter issues with public keys not being updated in a timely manner, so we can change the configuration file~/.gnupg/gpg.conf, change the PGP server address, and then download the public key again.

Demonstrating #1 above, verifying a signature incorrectly Example::

# gpg –verify linux-4.6.6.tar.sign linux-4.6.6.tar.xz

gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT

gpg: using RSA key 38DBBDC86092693E

gpg: BAD signature from “Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>” [unknown]

Verifying a signature correctly Example::

# gpg –verify linux-4.6.6.tar.sign linux-4.6.6.tar

gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT

gpg: using RSA key 38DBBDC86092693E

gpg: Good signature from “Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>” [unknown]

gpg: WARNING: This key is not certified with a trusted signature!

gpg: There is no indication that the signature belongs to the owner.

Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

Considerations When Programming

• Ensure strong update mechanisms and utilize cryptographic signatures for firmware images to update functionalities.

GPG(https://github.com/romanz/trezor-agent/blob/master/README-GPG.md)

• Ensure the security of download links, using TLS 1.2, TLS 1.3, or dedicated VPN links;

• Include a feature that utilizes automatic firmware updates according to a predefined schedule.

· In highly vulnerable use cases, enforce updates.

· For certain devices (e.g., medical devices), consider planned push updates to prevent issues caused by forced updates.

• Ensure firmware versions are clearly displayed.

• Ensure firmware updates include change logs with security-related vulnerabilities.

• Ensure a rollback protection mechanism is implemented to prevent devices from reverting to vulnerable versions.

• Consider implementing Integrity Measurement Architecture (IMA) so that the kernel can check file attributes (including extended attributes) through an Extended Verification Module (EVM) and verify files have not been altered based on stored/computed hash values (referred to as labels).

· There are two types of labels:

o immutable and signed

o Simple

• Ensure only appropriate applications can read and write to the filesystem;

· Apply appropriate controls and monitoring to approved processes that can write data to persistent storage locations.

• Ensure a trusted clock source exists between the device and the server.

4. Secure Storage of Sensitive Information

Do not hardcode secrets such as passwords, usernames, tokens, private keys, or similar variants into firmware release images. This also includes storing sensitive data written to disk. If a hardware security element (SE) or trusted execution environment (TEE) is available, it is recommended to utilize such features to store sensitive data. Otherwise, evaluate using strong cryptography to protect the data. If possible, all plaintext forms of sensitive data should essentially be ephemeral and only reside in volatile memory.

In the following example, secret is stored in amalloc allocated buffer, but depending on the CPU’s processing mechanism, this buffer is likely to beswapped to disk, and if the program crashes before callingmemset_s, sensitive information could be stored incoredump:

To prevent information from being written tocoredump, thecoredump generated by the program should be set to0

Additionally,mlock() can be used to prevent paging by locking memory in place. This compliant solution not only disables the creation ofcore dumps but also ensures that the buffer is not swapped to disk:

Considerations When Programming

• Do not hardcode credentials across product lines.

• Do not hardcode passwords across product lines.

• Do not store secrets in unprotected storage locations or external storage, including EEPROM or flash memory.

(1) From the kernel’s perspective, sensitive information allocated to buffers can be swapped to disk for performance considerations; thus, for sensitive data, we need to prohibitswap out;

(2) Free allocated space, the kernel does not immediately clear the content, but only clears it after a certain amount of space needs to be cleared or after a certain time; thus, for sensitive content, we need to force the kernel to execute the release operation immediately;

(3) A clearing operation merely reallocates that address space to other programs, generally not clearing the content at that address, thus we must manually callmemset_s to clear the content of that address segment beforefree.

5. Identity Management

User accounts in embedded devices should not be static. There should be functionality that allows separating user accounts for internalWeb management, internal console access, and remoteWeb management and remote console access to prevent automated malicious attacks.

Considerations When Programming

By setting the fields in/etc/login.defs:

• Static passwords for web management and terminal access across product lines should not be used or removed during release.

· If static default passwords need to be used during this period, ensure users are forced to change passwords after installation and activation of devices.

· Ensure users can choose to change all passwords/passwords/passphrases for all built-in accounts.

• Pre-production account validation scripts should be adjusted, similar to validating WIFI and WPS passwords (if applicable).

• Implement remote login and local login account functionality for users.

• Separate users for SSH login and administrator login.

• Remote login should implement temporary account lockout thresholds to prevent automated brute force attacks.

• For web management interfaces:

· Ensure sessionID is sent in the request body, not in theURL.

· Ensure sessionID is disabled when users log out.

· When changing passwords, ensure active sessions are disabled.

· If sessionID is stored incookie, ensure thecookie has the HttpOnly flag set.

· Ensure sessionID is random and changes between sessions.

• Ensure that user names, passwords, and cookies containing session IDs are not sent over insecure protocols (e.g., HTTP, FTP, and Telnet).

• A password complexity policy should be implemented to prevent easily guessable passwords such as “Password1”. Complex passwords should have the following properties:

· At least10 characters or more

· At least one uppercase letter

· At least one numeric character

· At least one lowercase letter

· At least one special character

• Ensure EEPROM is password protected to enhance complexity requirements.

• Implement key and certificate rotation policies.

6. Strengthening Embedded Frameworks and C-Based Toolchains

Limit BusyBox, embedded frameworks, and toolchains to only those libraries and functionalities used when configuring firmware versions. EmbeddedLinux build systems (e.g.,Buildroot,Yocto, etc.) typically perform this task. Removing known insecure libraries and protocols (e.g.,Telnet) not only minimizes the attack entry points in firmware builds but also provides a security-by-design approach to building software to thwart potential security threats.

Library Hardening Example: It is well-known that compression is insecure (and others),SSLv2 is insecure,SSLv3 is insecure, and early versions ofTLS are insecure. Additionally, assume you are not using hardware and engines, but only allowing static linking. With relevant knowledge and specifications, you can configure theOpenSSL library as follows:

$ Configure darwin64-x86_64-cc -no-hw -no-engine -no-comp -no-shared -no-dso -no-ssl2 -no-ssl3 –openssldir=

Selecting a Shell Example: The following screenshot utilizesbuildroot to demonstrate that only oneShellbash is enabled. (Note: Buildroot examples are shown below, but there are other ways to achieve the same configuration with other embeddedLinux build systems.)

Service Hardening Example: The following screenshot shows thatopenssh is enabled, but theFTP daemon proftpd andpure-ftpd are not enabled. FTP is only enabled when usingTLS. For example,proftpd andpureftpd require custom compilation to useTLS withmod_tls forproftpd, and pass./configure–with-tls forpureftpd.

U-Boot Hardening Example: Typically, physical access to embedded devices allows attack paths that can modifyBootloader configurations. Below are best practice examples ofuboot_config. Note: Theuboot_config file is typically auto-generated based on the build environment and specific board. For U-Boot 2013.07 and later, enable “Verified Boot” (Secure Boot). By default, “Verified Boot” is not enabled, and at least the following configuration is required for the motherboard to support it.

CONFIG_ENABLE_VBOOT=y# Enable verified boot

CONFIG_FIT_SIGNATURE=y# Enable signature verification for FIT images.

CONFIG_RSA=y# Enable RSA algorithm for FIT image verification

CONFIG_OF_SEPARATE=y# Enable independent build of u-Boot with device tree.

CONFIG_FIT=y# Enable support for Flat Image Tree (FIT) format.

CONFIG_OF_CONTROL=y# Enable flattened device tree (FDT) configuration.

CONFIG_OF_LIBFDT=y

CONFIG_DEFAULT_DEVICE_TREE=y# Specify the default device tree for U-Boot runtime configuration.

Afterwards, a series of steps need to be executed to configure“Verified Boot”. Building verified boot for theBeagleboneblack board example overview includes:

(1) BuildU-Boot for the board with verified boot options enabled.

(2) Obtain the appropriateLinux kernel (preferably the latest)

(3) Create anImage Tree Source (ITS) file that describes how you want the kernel to be packaged, compressed, and signed.

(4) Create anRSA2048 RSA key pair and authenticate usingSHA256 hashing algorithm (store the private key securely and do not hardcode it into the firmware).

(5) Sign the kernel

(6) Put the public key intoU-Boot image

(7) PutU-Boot and the kernel into the development board

(8) Test the image and boot configuration

In addition to the above, make applicable configurations effective for the context of embedded devices. Below are explicit configurations that can be made.

CONFIG_BOOTDELAY-2.# Prohibit access to u-boot’s console during automatic startup

CONFIG_CMD_USB=n# Disable basic USB support and usb commands

CONFIG_USB_UHCI: define low-level parts.

CONFIG_USB_KEYBOARD: enable USB keyboard

CONFIG_USB_STORAGE: enable USB storage devices

CONFIG_USB_HOST_ETHER: enable USB Ethernet adapter support

Disable serial console output inU-Boot using the following configuration macros:

CONFIG_SILENT_CONSOLE

CONFIG_SYS_DEVICE_NULLDEV

CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC

To enable immutableU-boot environment variables to prevent unauthorized changes (e.g., modifyingbootargs, updating verified boot public keys, etc.) or firmware’sside-loading, remove non-volatile memory settings such as the following:

#define CONFIG_ENV_IS_IN_MMC

#define CONFIG_ENV_IS_IN_NAND

#define CONFIG_ENV_IS_IN_NVRAM

#define CONFIG_ENV_IS_IN_SPI_FLASH

#define CONFIG_ENV_IS_IN_REMOTE

#define CONFIG_ENV_IS_IN_EEPROM

#define CONFIG_ENV_IS_IN_FLASH

#define CONFIG_ENV_IS_IN_DATAFLASH

#define CONFIG_ENV_IS_IN_MMC

#define CONFIG_ENV_IS_IN_FAT

#define CONFIG_ENV_IS_IN_ONENAND

#define CONFIG_ENV_IS_IN_UBI

Considerations When Programming

• Ensure services such as SSH have secure passwords created.

• Remove unused language interpreters such as: perl, python, lua.

• Remove dead code from unused library functions.

• Remove unused shell interpreters such as: ash, dash, zsh. Check /etc/shell

• Remove old insecure daemons, including but not limited to: telnetd, ftpd, ftpget, ftpput, tftp, rlogind, rshd, rexd, rcmd, rhosts, rexecd, rwalld, rbootd, rusersd, rquotad, rstatd, nfs, nis;

• Remove unnecessary utilities or set permissions for their usage, such as: sed, wget, curl, awk, cut, df, dmesg, echo, fdisk, grep, mkdir, mount(vfat), printf, tail, tee, test(directory), test(file), head, cat, at, cron;

• Harden specific services like ftp, generally for personal pcs, edit /etc/vsftpd/vsftpd.conf, set

Automotive GradeLinux (AGL) has developed a sample table listing common utilities and their usage in debugging or production environments (internal versions).

• Utilize tools like Lynis for enhanced auditing and recommendations

wget –no-check-certificate https://github.com/CISOfy/lynis/archive/master.zip && unzip master.zip && cd lynis-master/ && bash lynis audit system

Audit reports are stored in/var/log/lynis.log

• Conduct iterative threat modeling exercises with developers and relevant stakeholders regarding software running on embedded devices.

7. Debugging Code and Debug Interface Usage

Before releasing firmware, ensure that all unnecessary pre-production build code as well as invalid and unused code have been removed. This includes but is not limited to potential backdoor code androot privilege accounts that parties such as original design manufacturers (ODM) and third-party contractors may leave behind. Typically, this falls within the scope ofOEM executing contracts or reverse engineering binary files. This should also requireODM to sign a Master Service Agreement (MSA) to ensure no backdoor code is included and that all code has undergone a software security vulnerability review to hold all third-party developers accountable for devices marketed at scale.

Considerations to Keep in Mind

• Remove backdoor accounts used for debugging, deployment validation, and/or customer support purposes.

• Ensure development, diagnostic, or debugging functionalities are not included in the release version.

• Conduct code cleanup sessions to ensure invalid or unused code is removed from repositories.

• Before deploying to market, ensure staff have performed backdoor checks on third-party libraries and binary images.

• Tools such as Binwalk, Firmadyne, IDApro, radare2, Firmware Mod Toolkit (FMK), Firmware Analysis Comparison Toolkit (FACT), and various other tools should be used for firmware analysis.

8. Transport Layer Security TLS

Ensure all communication methods use industry-standard encryption configurations forTLS. The use ofTLS ensures that all data remains confidential and untampered during transmission. If embedded devices use domain names, utilize free certificate authority services such as “Let’s Encrypt”.

• Use the latest version of TLS for new products (as of writing, this is TLS 1.2)

• Consider implementing TLS mutual authentication for firmware that accepts TLS connections from a limited set of allowed clients.

• If possible, consider mutual authentication for both endpoints.

• Verify the public key, hostname, and chain of the certificate.

• Ensure certificates and their chains are signed with SHA256.

• Disable deprecated SSL and early TLS versions.

• Disable deprecated NULL and weak cipher suites.

• Ensure private keys and certificates are securely stored – for example, in a secure environment or trusted execution environment, or protected using strong cryptographic techniques.

• Use the latest security configurations to update certificates.

• Ensure effective certificate renewal functionality is available when certificates expire.

• Use services like ssllabs.com, nmap, etc. to validate TLS configuration using tools such as –script ssl-enum-ciphers.nse, TestSSLServer.jar, sslscan, and sslyze.

In addition to usingopenssl to implementTLS, you can also use:

Formerly PolarSSL, usingmbedTLS:

·https://tls.mbed.org/kb/generic/projects-using-mbedtls

·https://tls.mbed.org/

https://tls.mbed.org/kb/how-to/mbedtls-tutorial

Previously CyaSSL,wolfSSL, using a series of projects fromwolfSSL:

·https://www.wolfssl.com/wolfSSL/wolfssl-embedded-ssl-case-studies.html

·https://www.wolfssl.com/wolfSSL/Home.html

· https://github.com/wolfSSL/wolfssl-examples

9. Use of Data Collection and Storage – Privacy

Limit the collection, storage, and sharing of personally identifiable information (PII) and sensitive personal information (SPI). Leaked information such as social security numbers can harm customers and may have legal implications for manufacturers. If it is necessary to collect information of this nature, the concept of “Privacy-by-Design” must be adhered to.

Considerations to Keep in Mind

• Determine which PII/SPI is critical for device operation and whether the information required for business and/or operational purposes is stored.

• Limit the duration of storage to the minimum time necessary for device operation.

• Ensure information is securely stored – that is, in a secure environment or protected using strong encryption.

• Provide customers with detailed information about what information is collected, stored, and distributed through the privacy policy;

• Provide a mechanism for device owners to perform factory resets to delete their personal data before transferring to other users or destroying it.

• Consider GDPR for devices storing data in the EU.

10. Third-Party Code and Components

After setting up the toolchain, it is important to ensure that the kernel, packages, and third-party libraries are updated to prevent publicly disclosed vulnerabilities. They should be checked against vulnerability databases and theirChangeLog to determine when and if updates are needed. It is important to note that this process should be tested by developers and/or QA teams before a release version, as updates to embedded systems can cause these systems to malfunction.

Embedded projects should maintain a “materials list” of third-party software included in their firmware images. This materials list should be checked to confirm that none of the third-party software included has any unpatched vulnerabilities. The latest vulnerability information can be found through national vulnerability databases or open centers.

There are several solutions available for classifying and auditing third-party software. Many solutions are built into your build environment, such as:

·C/C++

· Makefile

· Go

· Use the officialdeptool

· Node

· npmlist

· Python

· pipfreeze

· Ruby

· gemdependency

· Lua

· See therockspecfile

· Java

· mvndependency:tree

· gradleapp:dependencies

· Yocto

· buildhistory

· Buildroot(free)

· makelegal-info

· Package Managers(free)

·

dpkg–list

· rpm-qa

· yumlist

· aptlist–installed

· RetireJS for Javascript projects (free)

Considerations to Keep in Mind

• Scan JavaScript Libraries using retire.js

• Use npm audit for NodeJS packages

• Utilize OWASP DependencyCheck for detecting publicly disclosed vulnerabilities in application dependencies and file types.

• Use safety check to scan known vulnerabilities in Python-related packages

• Use OWASP ZAP for web application testing

• Use tools like Lynis for basic kernel hardening audits and recommendations.

· wget –no-check-certificate https://github.com/CISOfy/lynis/archive/master.zip && unzip master.zip && cd lynis-master/ && bash lynis audit system • Audit reports are stored in:/var/log/lynis.log • Note: If not using the Linux kernel, Lynis will skip kernel checks. The following error message will appear in the logs: “Skipping testKRNL-5695 (Determine Linux kernel version and release number) skipped due to: Incorrect client OS (Linux only)” • If storage space is limited (i.e., remove unnecessary plugins such asphp, etc.), Lynis should be modified accordingly.

Utilize free library scanners likeLibScanner, which can search project dependencies and cross-reference them with the NVD for known CVEs for the yocto build environment. This tool outputsXML, allowing teams to leverage these capabilities for continuous integration testing.

• Utilize package managers (opkg, ipkg, etc.) or custom update mechanisms for miscellaneous libraries in the toolchain.

• Review changelogs for tools, packages, and libraries to better determine if updates are needed.

• Ensure implementations for embedded systems like Yocto and Buildroot allow for updates to all included packages.

11. Threat Modeling

Threat modeling is an exercise that helps quantify threats to understand how attackers (threat actors) can compromise the system, and then take appropriate mitigation measures to prevent potential risks. Typically, threat modeling is conducted as part of the design phase before deployment to production systems but can also be applied at the beginning of any security testing. Threat modeling typically includes the following activities:

• Identify all assets in the system, create an architectural overview

• Decompose the system (or device)

• Identify threats

• Document all threats and their respective contexts

• Rate each threat by likelihood and impact using a rating system

The threat model should answer the following four questions:

• What are we building?

Use data flow diagrams (DFD) to assist in modeling components and how they interact locally and with external services

DFD should show each process connecting assets, users, entities, data stores, and protocols

Utilize tools like Microsoft Threat Modeling Tool 2016, OWASP Threat Dragon, or online diagram software likehttps://draw.io/ orhttps://www.lucidchart.com.

• What could go wrong?

UtilizeSTRIDE to help identify and enumerate threats

• What do we do about the potential issues?

DREAD aids in risk scoring and prioritization. The higher the risk, the higher the priority to address or mitigate the threat.

• How effective is our analysis?

Conduct retrospective activities to review overall quality, progress, and future plans.

Threat modeling should be done as early and as frequently as possible. The owner of the threat model is best kept in the hands of the software team and should be viewed as a living document that is updated as new features are planned. A great book, also an authoritative reference, is“Threat Modeling: Designing for Security”.

12. Conclusion

“Embedded Application Security Best Practices” provides a detailed technical introduction on how to protect embedded systems, and in practical applications, we can optimize based on specific automotive usage scenarios, such as for unsafe functions, we can refer toCert C andMisra C for improvement.

Overall, as practitioners in automotive cybersecurity, whether in ourTARA analysis or later testing and validation,OWASP is a great reference source for free materials, and Qingji will present more content for everyone in the future.

END

Join WeChat Group

Tansilab focuses on intelligent automotive information security, expected functional safety, autonomous driving, Ethernet, and other automotive innovative technologies, providing the highest quality learning and communication services for the automotive industry, and relying on strong industry and expert resources, committed to building a first-class efficient business platform for the automotive industry.

Every year, Tansilab holds dozens of online and offline brand events, has dozens of boutique thematic communities for intelligent automotive innovative technologies, covering nearly a hundred leading automotive manufacturers’ experts both domestically and internationally, including BMW, Daimler, PSA, Audi, Volvo, Nissan, GAC, FAW, SAIC, NIO, etc., and has served tens of thousands of practitioners in the upstream and downstream industry chain of the intelligent automotive industry. Exclusive communities include: Information Security, Functional Safety, Autonomous Driving, TARA, Pentest, SOTIF, WP.29, Ethernet, IoT Security, etc., and the current thematic communities are still open for entry until full.

Scan the QR code to add WeChat, and according to the prompt, you can enter the thematic group chat of interest, enjoying the latest news and interacting with industry experts.

Tansilab, empowering automotive technology, promoting industrial innovation and development!