Have you identified security assets in your radio equipment? If not, you may find it challenging to begin your EN 18031 Technical Documentation.

The primary goal of all EN 18031 standards (i.e., EN 18031-1, -2, and -3) is to safeguard security assets. These standards assume that you have already identified all security assets before you start drafting your Technical Documentation. Consequently, achieving compliance with EN 18031 is impossible without thorough documentation of the security assets in your device.

However, the concept of "security assets" can be difficult to grasp. We often hear from manufacturers that the explanations and definitions provided in EN 18031 are too ambiguous and lack concrete examples.

In this article, we will clarify what security assets are. By the end of this article, you will gain insights into:

• The official definitions of security assets
• Our interpretation of these definitions to provide a clearer understanding of what security assets truly encompass
• The thought process to adopt when identifying security assets
• How to use open-source firmware analyzers (EMBA & FACT) to identify security assets
• 30 real-life examples of security assets

Security Assets Categorization: Security Functions and Security Parameters

According to the standards, security assets are classified into two main categories: Security functions and security parameters. Together, they work in tandem to achieve specific security objectives, such as implementing a firewall or protecting the confidentiality of communications through cryptography.

In essence, security parameters define the behavior of security functions. For example, if you have a firewall as a security function, the file(s) used to configure that firewall can be considered security parameters.

Do you see the relationship between security functions and parameters? They are not independent elements; rather, they form a cohesive set of assets that work together to achieve a specific security goal. Keep this relationship in mind while working on your Technical Documentation.

1. Security Functions

Official Definitions of Security Functions

The definitions of security functions in hEN 18031 vary depending on the standard applied:

• hEN 18031-1defines a security function as "functionality on the equipment that is relevant to protect it from harming the network or its functioning or misusing network resources".
• hEN 18031-2 defines a security function as a "measure on the equipment that ensures that the personal data and the privacy of the user and of the subscriber are protected".
• Annex A of the standardsprovides a more general definition stating that "security functions are used to protect network assets [or privacy assets] or other security assets. For example, the implementation of an access control mechanism is a security function."

Our Interpretation of Security Functions

Security functions are any functionalities/measures implemented in the equipment aiming at fulfilling various security-related objectives.

Examples of such security objectives include:

• Protecting the equipment from unauthorized access and compromise (e.g., firewall)
• Protecting the equipment's resources and data stored and communicated over a network (e.g., protecting their integrity & authenticity)

You can start identifying security functions by asking yourself what functionalities are implemented in the equipment to fulfill these objectives.

Cryptography often plays a crucial role in fulfilling the aforementioned security-related objectives. It is commonly used by various equipment's mechanisms including:

• Update mechanisms (e.g., to verify the integrity and authenticity of an update package)
• Communication mechanisms (e.g., to protect the confidentiality, integrity and authenticity of data communicated)
• Storage mechanisms (e.g., to protect the confidentiality and integrity of data stored)

Since the term "security function" may be too conceptual and subject to varying interpretation, we propose to the following four categories to document security functions:

• Cryptographic protocol implementations/libraries
• Security-related client applications
• Security-related server applications and services/daemons
• Other "finer-grain" functions

📝Note: In our preview article on Network Assets (read on LinkedIn or on Zealience Resource Hub), we explained how network functions can be identified by considering the (network-relevant) client and server applications present in the equipment. When you apply hEN 18031-1, it will be beneficial to review these explanations to better grasp the interplay between network functions and security functions.

Let's unpack those four categories below.

1. What Are Cryptographic Protocol Implementations

Cryptographic protocol implementations enable equipment to utilize cryptographic algorithms and protocols. When one says that an equipment uses a given cryptographic algorithm/protocol, there is usually a specific implementation (e.g., a library) that is used to enable the equipment to do so. For example, a device can leverage the Mbed TLS library which implements various cryptographic protocols (e.g., TLS) and algorithms (e.g., SHA-3, AES, and RSA). It is strongly recommended to only rely on vetted and recognized libraries rather than implementing cryptographic protocols/algorithms oneself.

It is worth noting that identifying cryptographic protocol implementations is not only needed in the context of security function, but also for cryptographic-related requirements such as CRY-1 and CCK-1, -2 and -3.

How To Identify Them

A good starting point to find cryptographic protocol implementations is to look for the different mechanisms in an equipment and assess whether they make use of cryptography. For example, when a web server on the equipment supports encrypted communication over HTTPS, there is likely a cryptographic library enabling the usage of its implementation of TLS. You can also review the filesystem and search for libraries and kernel modules related to cryptography. We elaborate below on the tools that can assist you.

2. What Are Security-Related Client Applications?

Security-related client applications generally enable the equipment to utilize network resources securely. For example, an SSH client can be used by the equipment to connect to an SSH server on another device.

How To Identify Them

To document such applications, review the list of applications available on your device to identify those involved with security objectives. You can examine the binaries in the firmware's file system. A firmware analyzer like EMBA can assist in identifying these binaries. We will explain how to use EMBA below.

3. What Are Security-Related Server Applications and Services/Daemons?

Security-related server applications and services enable the equipment to securely provide network resources to other devices on the network. For example, the equipment can have an SSH server to allow other devices' SSH client to connect to it securely.

How To Identify Them

Similarly to client applications, you can review the list of applications and identify such server applications and services. We also recommend scanning your device's network interfaces with appropriate tools to identify exposed security services. For services exposed on IP-based network interfaces, use Nmap to identify them.

This is essential for the functional completeness assessment of the requirement GEC-4, as the verdict PASS can only be obtained if all exposed services are documented accordingly.

4. Other "Finer-Grain" Functions

While security functions can be stand-alone applications and libraries, they can also be functionalities of another application. For example, a web server (i.e., considered a network function under hEN 18031-1) can have a login page to authenticate users. This login page can be regarded as a security function since it is an implementation of an authentication mechanism. This is aligned with the standards, giving the example of an "implementation of an access control mechanism [as] a security function."

It can ease the documentation effort to decompose certain applications into relevant functions. For instance, when applying any of the standards (-1, -2 and -3) for an equipment, a single application can actually be composed of security functions, network functions, privacy functions and/or financial functions. The standards do not impose a level of granularity regarding the decomposition into functions. It is best to always refer to the definitions of the standards to discern what constitutes a security function in the context of another application.

How To Identify Them

Review the applications used by the equipment, especially those involved with network communication (e.g., applications accessible via network interfaces, applications receiving/processing/sending data to communication peers). Based on the standard(s) applied, consider the definition of security functions and identify whether the aforementioned applications have such functions. For example, does the application have specific functions to protect the equipment (hEN 18031-1), user's personal data (hEN 18031-2) or financial data (hEN 18031-3)? If yes, you may want to document them accordingly.

How to Use Open-Source Tools To Identify Security Functions

In this section, we explore how EMBA and FACT (Firmware Analysis and Comparison Toolkit) can help you identify security assets. These two open-source firmware analyzers are quick and easy to install (refer to their respective GitHub pages for installation instructions and usage). Everything runs locally, meaning that your firmware and analysis results stay on your computer. With just a couple of commands, you can start finding binaries of security-related client/server applications and cryptographic protocol libraries in your device's firmware.

EMBA and FACT are designed for security analysis of IoT devices' firmware. While we focus in this article on their usage for the identification of security assets, we will cover in a future article how to use them to conduct security testing required for hEN 18031 self-assessment.

Let's take a look at the firmware of the open-source router, OpenWRT One, to identify some of its security assets.

How To Use EMBA to Identify Security Functions

Starting with EMBA, you can scan the firmware by executing the following command in the folder where you installed EMBA:

./emba -l ./log -f /path/to/firmware -p ./scan-profiles/default-scan.emba

EMBA offers a number of scan profiles which will run different modules to perform various analyses; for our purpose, this default scan is sufficient. Feel free to experiment with others.

Once the scan completed, you can access an HTML report generated by EMBA. Navigate to the folder where you stored the scan results (in our case, /log) and open the file index.html in the html-report folder. Directly in the main page, you will find an inventory of some of the software present in the firmware. Review the list to identify applications to be documented as security functions, such as dropbear_ssh and wpa_supplicant.

(Note: We will cover in another article how to leverage those results to meet the requirement GEC-1.)

There may not always be a clear cut answer on whether an application must be documented as security function or network function. For instance, Dropbear SSH and wpa_supplicant could also be considered network functions. If needed, document them as both security and network functions and focus their respective description on the security-/network-relevant features they offer. As discussed above in 4., the degree of decomposition is up to you.

Back in EMBA, on the left sidebar, you can navigate to "Firmware and testing details" to browse the filesystem (squashfs) extracted from the firmware. The following folders are particularly interesting to review to identify security functions:

• /bin
• /etc
• /etc/init.d and /etc/rc.d, depending on the Linux distribution used by firmware. Look especially for the scripts in rc.d starting with S since they will be used to start the respective services at device startup.
• /lib/sbin
• /usr/bin and usr/sbin
• /usr/lib

By going through these folders, we can find applications and binaries of client/server applications to be documented. We can also find interesting libraries in the folder /usr/bin/: In the screenshot above, we can see a number of cryptographic libraries relevant for documentation. For example, libmbedcrypto, libmbedtls and libmbedx509 are good candidate for security functions as discussed earlier.

How To Use FACT to Identify Security Functions

Moving on to FACT, let's see how this firmware analyzer can also be used to identify security assets. Similarly to EMBA, it can perform various in-depth analyses of firmware for embedded devices, but we focus here on the use case of asset finding.

Note: Using different tools is beneficial to cross-check results and can increase the confidence in the completeness of the Technical Documentation.

After installing FACT, open your browser and go to localhost:5000. Click on Upload in the top bar to upload your firmware. You can then select which analyses you want to perform, as shown in the screenshot below.

We suggest selecting the following options to search for security functions:

• Crypto hints: "Find indicators of specific crypto algorithms"
• ELF analysis: "Analyzes and tags ELF executables and libraries"
• Init systems: "Detect and analyze auto start services"
• Software components: "Identify software components"

Once the analysis completed, you can click on "Database", then "Browse Firmware" and select your firmware. Let's have a look at the software components identified: Click on "software components" in the left bar, then on "Load Summary for Included Files".

With some slight differences compared to the software inventory analyzed by EMBA earlier, we can find the same security functions such as OpenSSH (dropbear) and wpa_supplicant (not shown in the screenshot).

To ensure a complete documentation of security functions, consider also using other tools such as network scanners to identify services exposed on network interfaces. For IP-based network interfaces, the tool of choice is Nmap. There are plenty of tutorials available online explaining how to scan your device. Scanning your device is essential for the functional completeness assessment of the requirements GEC-2, GEC-3 and GEC-4, as the verdict PASS can only be obtained if all services found exposed are documented accordingly.

Examples of Security Functions

Below are examples of security functions:

• "Implementation of an access control mechanism" (From EN 18031)
• Cryptographic protocol implementations and libraries: Mbed TLS, OpenSSL, wolfSSL
• Firewall
• SSH server/client
• VPN client
• Web server using TLS for secure communication

Are there any additional examples on your device? Let us know so we can include them here!

2. Security Parameters

Official Definitions of Security Parameters

The standard hEN 18031-1 defines a security parameter as "data processed by the equipment that defines the behavior of the equipment's security function".

Security parameters can be confidential and/or sensitive:

• Confidential security parameter (CSP) is defined as "secret security related information whose disclosure can compromise the security of an asset."
• Sensitive security parameter (SSP) is defined as "security related information whose manipulation can compromise the security of an asset."

Our Interpretation of Security Parameters

As mentioned earlier, security parameters define the behavior of security functions. In other words, the security parameters relevant for your Technical Documentation are those used by security functions.

For example, if the equipment utilizes a cryptographic library (i.e., security function) to secure the communication to its web server (i.e., network function), the cryptographic keys and certificates used need to be documented as security parameters.

Another example can be the authentication mechanism of a web interface using passwords to authenticate users; the password will need to be declared. It will also be declared as authenticator used by the respective authentication mechanism (see requirements AUM-5-1 and AUM-5-2 focusing on passwords).

See below other typical examples of security parameters which may be declared.

Classification of Security Parameters: Confidential vs. Sensitive

Security parameters can be confidential, meaning that their confidentiality needs to be protected (e.g., passwords), and/or they can be sensitive, meaning that their integrity needs to be protected (e.g., public keys).

While the hEN 18031 standards mention that a security parameter can be sensitive and/or confidential (see Annex A of the standard), we consider that it should be either sensitive, or confidential AND sensitive. This excludes the possibility to have a security parameter that is only confidential: In light of the security objectives that must be met, we believe that if confidentiality needs to be protected, then integrity must also be safeguarded.

The Classification Affects the Applicability of Requirements

The classification of parameters leads to different requirements from the standards to be applied. For example, when security parameters (regardless confidential or sensitive) are stored persistently in the equipment, the storage mechanism must protect their integrity (requirement SSM-2). When confidential security parameters are persistently stored, the storage mechanism needs also to protect their confidentiality (requirement SSM-3). It is therefore essential to identify and classify assets appropriately, as they determine the applicable requirements. This also means that it is not possible to identify the applicable requirements of the standards without having first identified the assets.

How to Use Open-Source Tools To Identify Security Parameters

We can use the firmware analyzers EMBA and FACT introduced earlier to identify certain security parameters. You can use them to scan your firmware and identify certain security parameters (or hints of their presence) such as cryptographic keys, certificates, passwords or configuration files (used to configure security functions).

EMBA to Identify Security Parameters

Starting with EMBA, we can go back to the HTML report of the previous scan and look at different sections in the left bar. The relevant ones which could indicate the presence of security parameters are listed below. They correspond to specific modules that EMBA executed during the scan.

• Search password files: This module searches for password-related files (e.g., passwd, shadow) and identifies (root) accounts.
• Deep analysis of files for interesting key material: This module searches for specific patterns in files to spot potential signs of private keys in them.
• Deep analysis of files for password hashes: This module searches for password hash values in files.
• STACS analysis of firmware for password hashes: This module uses the STACS engine (Static Token And Credential Scanner) to look for password hash values.

Review the results provided by these modules to identify potential passwords and cryptographic keys in the firmware.

Regarding other types of security parameters, you can also browse the filesystem and search of configuration files used by security functions (keep in mind the relationship between them as defined in the standards). To do so, go to the section "Firmware and testing details" in EMBA's HTML report. For each security function identified as described above, look for files suggesting that they configure the given security function. One particular folder to examine is /etc/config, where configuration files for various services are conventionally stored. In the screenshot below, we can see the config files for Dropbear SSH and firewall (fw4). However, make sure not to overlook other locations: Some security functions (e.g., client or server applications) can have their own dedicated folder containing their configurations.

FACT to Identify Security Parameters

Moving on to FACT, we can execute additional tests to identify security parameters. To do so, go back to the results of the analysis previously conducted (click on "Database", then "Browse Firmware" and select the firmware). In the left bar, click on "Run additional analysis". Under "Add new analysis", we can select the following options to search for security parameters:

• Crypto material: "Detects crypto material like SSH keys and SSL certificates"
• Users and passwords: "Search for UNIX, httpd and mosquitto password files, parse them and try to crack the passwords"

Taking as example "Crypto material", we can click on "Load Summary for Included Files" and see that FACT identified a public key (openwrt-snapshots.pem) and an SSL/TLS certificate (actually ca-certificates.crt, a file that contains a list of trusted Certificate Authorities certificates). These files are definitely sensitive and their integrity needs to be protected, hence we can document them as sensitive security parameters.

Examples of Security Parameters

Below are the examples of sensitive security parameters:

• Certificate
• Public key
• Ciphertext
• Signature
• Digest
• Salt
• Message Authentication Code/Tag
• Configuration files of security-related services and other security functions*

Below are the examples of confidential and sensitive security parameters:

• Password
• Private key
• Symmetric (secret) key
• Key
• Seed
• Shared secret
• Token
• Configuration files of security-related services and other security functions*

* Configuration files can be classified as sensitive or confidential AND sensitive depending on the kind of information they contain. For example, we identified earlier wpa_supplicant as a security functions. It can use configuration files which may contain pre-shared keys. In such cases, the config files must be documented as confidential.

This list is inspired by another standard, CycloneDX v1.6, which defines a way to express Bills of Material (BOM), including Cryptographic BOM (CBOM). It offers a great starting point to start thinking about what constitutes a security parameter.

The list of security parameters we propose above is not exhaustive, nor should you expect to find all of them in your device. Instead, it should serve as a reference to kick-start compliance work by asking informed questions. We believe that an engineering team can complete the Technical Documentation faster by going through each security parameter in this list and asking "Does the equipment use [security parameter], and if so, for what purpose, how is it used, and where is it stored?" This approach is more effective than remaining stuck on the question, "What are security parameters?"

Thanks a lot for reading! Stay tuned for the next part of this Ultimate Guide in which we will delve into privacy assets.

Ready To Start Your hEN 18031 Compliance?

You can download our free and open-source Technical Documentation templates from our GitHub repository. If you have questions about its usage, simply shoot us a line!

• EN 18031-1, -2 and -3 Technical Documentation template
• EN 18031-1, -2 and -3 Test plan template

Author of This Article ✏️

Dr. Guillaume Dupont is a co-founder of Zealience. He holds a PhD in IoT cybersecurity. As a former Senior Security Expert at UL Solutions, he helped IoT manufacturers prepare for the RED DA by performing evaluations against product security standards such as ETSI EN 303 645 and IEC 62443-4-2. He has contributed to the drafting of EN 18031 and also trained a Notified Body for RED DA assessments. He previously worked at Forescout on automotive security and developed intrusion detection systems for in-vehicle networks. He is also a seasoned IoT vulnerability researcher and disclosed CVEs found in medical devices to Siemens Healthineers. His research on IoT security led him to obtain a US patent: He invented a novel approach to enhance the accuracy of IoT device classification leveraging machine learning algorithms (US20220353153).