Encryption

The most important information in brief

What does encryption mean for embedded systems?

In embedded systems, encryption is not a single software module that is appended to an application afterward. It is part of the device architecture and must be considered in conjunction with memory structure, communication paths, boot process, update mechanisms, diagnostic access, and user or service roles. For example, a device can capture measurement data, store parameters, communicate via a fieldbus or IP connection, and receive firmware updates. Data arises at several of these points, which must be protected against unauthorized access or manipulation.

The project therefore begins with the question of which data flows and storage areas exist. This includes internal connections between microcontrollers, memory modules, and peripherals, as well as external interfaces to gateways, user interfaces, cloud services, service tools, or production systems. Only when these pathways are described can it be determined which data will be encrypted, where keys will be stored, and what checks will take place before access.

Encryption can fulfill various tasks. It can establish confidentiality, by making data readable only with the correct key. It can support integrity, if changes to data are detected. In combination with authentication, it can ensure that a device, an update package, or a communication partner belongs to an expected source. In embedded projects, these goals are often considered together, because a single security mechanism rarely covers all risks.

A typical topic is the boundary between software and hardware. Some platforms offer hardware features for cryptographic operations, protected memory areas, or isolated execution environments. Other systems need to be secured more heavily through software, bootloaders, memory layout, and process specifications. In such cases, PICKPLACE assesses which functions are available on the existing hardware and how they can be integrated into the firmware or system software.

The lifecycle of a device also influences encryption. Keys must be able to be generated, stored, used, renewed, and, if necessary, revoked. A procedure that works in the lab must also remain manageable in manufacturing, service, maintenance, and field operation. This includes questions such as: Who is allowed to initialize a device? How are secrets introduced during production? What happens when a component is replaced? How is it prevented that diagnostic access provides uncontrolled access to protected data?

For PICKPLACE, encryption in embedded systems therefore means a combination of security concept, software development, and technical classification of the target platform. The focus is on examining concrete attack surfaces and data paths and deriving actionable measures from them.

What data on a device should be protected?

Not all information in a device requires the same level of protection. Therefore, a project distinguishes which data is confidential, which data must remain unchanged, and which data should be accessible in case of errors or during maintenance. This classification prevents blanket measures and creates a basis for architectural decisions.

Commonly protected data includes credentials. These can be passwords, tokens, certificates, private keys, or device-specific identities. If such information is exfiltrated, attackers may be able to impersonate devices, hijack communication connections, or misuse service functions. In embedded systems, the question arises not only about encryption itself but also about its storage location. Credentials should not appear unprotected in flash memory, configuration files, or debug outputs.

Configurations can also be susceptible to protection. Parameters often determine how a device operates, which limits apply, which interfaces are active, or which operating modes are permitted. Unauthorized changes can trigger malfunctions or disable security functions. Encryption alone is not always sufficient here. Integrity checks, signatures, or role-based authorizations are often additionally required so that changes are detected and only adopted through intended channels.

Operating data and diagnostic information must also be evaluated. Measured values, statuses, error logs, and log data can provide insights into system operation, usage behavior, production processes, or technical vulnerabilities. If such data can be retrieved via service interfaces, local storage media, or remote access, it should be determined which information is stored encrypted or only transmitted via protected channels.

Firmware and software packages are another area of protection. An update must not only be transported but also verified before installation. This involves determining whether the package originates from an expected source and whether it has been altered since its creation. For sensitive content, encryption of the update package may also be necessary to prevent the disclosure of code, configurations, or included keys. The exact solution depends on whether a bootloader, a secure boot mechanism, or an existing update procedure is in place.

Devices with multiple operating modes create additional boundaries. A manufacturing mode requires different access than a service mode or normal field operation. Test functions, debug interfaces, and internal commands may be necessary during the development process, but must not remain uncontrolled in the delivered device. This is where encryption connects with secure hardening: unnecessary access is removed or restricted, remaining access is secured, and sensitive outputs are avoided.

PICKPLACE considers such data classes together with existing interfaces. This results in a protection matrix, which combines data types, storage locations, access paths, and measures. This matrix can serve as a basis for software changes, hardware assessment, test planning, and documentation.

Encryption protects communication between devices by scrambling the data so that only authorized parties can decipher it. When data is encrypted, it's converted into a code that looks like random characters. This coded data can only be decoded back into its original form using a special key, similar to a password. Here's a breakdown of how it works: * **Sender Encrypts:** When device A wants to send a message to device B, it uses an encryption algorithm and a secret key to scramble the message. * **Scrambled Transmission:** The scrambled message (ciphertext) travels across the network. If intercepted, it appears as gibberish to anyone without the key. * **Receiver Decrypts:** Device B receives the scrambled message and uses the corresponding decryption key (which is often derived from the same key used for encryption, or a related key) to unscramble it back into its original, readable form (plaintext). **Key Concepts:** * **Encryption Algorithm:** A mathematical process used to encrypt and decrypt data. Examples include AES (Advanced Encryption Standard) and RSA. * **Key:** A piece of information (like a password or a complex string of characters) that is used with the encryption algorithm to transform the data. * **Symmetric Encryption:** Uses the same key for both encryption and decryption. This is fast and efficient, but securely sharing the key between devices can be a challenge. * **Asymmetric Encryption (Public-Key Cryptography):** Uses a pair of keys: a public key (which can be shared widely) for encryption and a private key (kept secret) for decryption. This solves the key distribution problem. **How it protects communication:** * **Confidentiality:** Prevents unauthorized access to the content of the communication. Even if someone intercepts the data, they cannot understand it without the decryption key. * **Integrity:** Some encryption methods also ensure that the data has not been tampered with during transmission. They can detect if any changes have been made to the message. * **Authentication:** In some cases, encryption can also verify the identity of the sender, ensuring that the message truly originated from the expected source. In essence, encryption acts like a secure vault for your data while it's in transit, ensuring that only the intended recipients can unlock and read its contents.

Communication between devices is a key application area for encryption in embedded projects. Data can be transmitted via wired interfaces, wireless connections, local networks, mobile networks, industrial protocols, or gateway structures. Without appropriate protective measures, content can be eavesdropped on, altered, replayed, or sent to incorrect recipients.

Security begins with defining the communication partners. A device must be able to verify if it is speaking with an expected counterpart. Depending on the system, this can be done via keys, certificates, shared secrets, or other authentication mechanisms. Only then is it determined how payload data will be encrypted and how messages will be secured against tampering. For the project, it is crucial whether the communication relationship is established permanently, for a limited time, device-specifically, or group-related.

In symmetric encryption, the sender and receiver use the same secret key. This can be practical for well-defined device networks, but it places demands on the secure distribution and storage of this key. Asymmetric methods use key pairs, allowing identities and signatures to be mapped differently. Which variant is used depends on computing power, storage, existing protocols, manufacturing processes, and maintenance requirements.

In addition to confidentiality, the integrity of the transmitted data must be verified. An encrypted data stream is not automatically sufficiently protected against manipulation if no suitable message authentication is provided. Therefore, in implementation, methods are used that detect whether a message has been altered. Additionally, counters, nonces, or time references can prevent old messages from being replayed.

Integration into existing protocols must also be clarified. Some systems can utilize established transport-layer security mechanisms. Others use proprietary or highly restricted protocols where protection mechanisms must be integrated into the application layer. In such cases, PICKPLACE analyzes at which point encryption can be technically integrated meaningfully without unnecessarily altering device functionality or existing interfaces.

Another point is the behavior in case of errors. If a key check fails, a communication partner is unknown, or a message cannot be decrypted, the device must react in a defined way. It should not reveal sensitive information via error messages and should not activate insecure fallback mechanisms. At the same time, diagnostics and service must still be possible in a way that allows errors in the field to be traced. A balance between security requirements and maintainability often arises here.

In networked devices, key management throughout the lifecycle also plays a role. Devices can be replaced, reprovisioned, decommissioned, or integrated into other clusters. If keys cannot be changed or revoked, long-term risks arise. Therefore, the architecture already defines how initialization, key changes, and revocation will proceed technically and organizationally.

Example Technologies

• Security Stack wolfSSL
• Security Stack Mbed TLS
• Trusted Execution Environment Arm TrustZone / Trusted Execution Environment
• Hardware Security NXP Hardware Security Engine HSE
• Bootloader MCUboot

Our Services

PICKPLACE supports projects for encryption in embedded systems from analysis to implementation. The work often begins with an inventory of existing hardware, firmware, communication interfaces, and storage areas. Data types, access paths, and existing protection mechanisms are recorded. From this basis, it can be determined where encryption is needed and what additions are required for integrity checking, authentication, or access control.

As part of a security concept, we are structuring the technical decisions. This includes the classification of data requiring protection, the definition of communication relationships, the selection of suitable procedures within the existing platform, and the description of key management. The concept forms a working basis for development, review, testing, and later maintenance. It can also highlight open issues, such as missing hardware functions, unclear manufacturing processes, or diagnostic accesses that need to be adapted.

In software development, we implement security measures in firmware, system software, or accompanying tools. These can include encrypted storage of configurations, secured communication paths, verification of update packages, handling of device keys, or adaptations to the boot and update process. The exact scope depends on the existing architecture and the goals defined in the project.

Secure hardening includes measures that reduce existing attack surfaces. These include checking debug and service access, managing log output, securing diagnostic functions, restricting unnecessary interfaces, and evaluating default passwords or static secrets. Encryption is not considered in isolation but is aligned with the actual access possibilities on the device.

If a platform supports TrustZone, PICKPLACE can collaborate in classifying and utilizing this separation. This involves checking which functions should be executed in a protected area, which data should be stored or processed there, and how communication between the protected and normal execution environments will be designed. TrustZone does not replace a complete security concept, but it can help to more strongly separate sensitive key operations or access controls from the rest of the application code.

Technical documentation is also part of the project work. Encryption methods, key management processes, data flows, error behavior, and assumptions must be credibly described so that development, testing, manufacturing, and service all work with the same fundamentals. PICKPLACE documents these points so that later changes to the device or software do not occur without considering the security architecture.