Bosch IoT Rollouts

S&E Features

The Sign & Encrypt extension is designed as a cloud service. The following graphic provides a high-level perspective on the different modules of the service:

images/confluence/download/attachments/2441717257/rollouts-features-version-1-modificationdate-1731053292000-api-v2.png

Key management

  • Symmetric keys

  • Asymmetric keys

  • X.509 Certificates (managed by 3rd party)

Packaging

  • Default packaging

  • Project / customer specific container format can be added on demand

Encryption

  • Ciphers

    • AES256_CBC_PKCS7_PAD

    • AES128_CBC_PKCS7_PAD

    • AES256_CBC_ZERO_BYTE_PAD

    • AES256_ECB_ZERO_BYTE_PAD

    • AES128_ECB_ZERO_BYTE_PAD

    • AES128_CTR_NO_PAD

  • Others can be added on-demand

Signing

  • Ciphers

    • RSA_3072

    • RSA_4096

    • ECC_NIST_P256

    • ED25519

    • SHA256_PKCS_V15 (only with 3rd party PKI)

    • SHA256_ECDSA (only with 3rd party PKI)

    • SHA256_PSS (only with 3rd party PKI)

    • SHA512_PSS (only with 3rd party PKI)

  • Others can be added on-demand

3rd Party Public Key Infrastructure (PKI)

  • Escrypt.KMS X.509 PKI

  • Others can be added on-demand

Interfaces

Authentication

Highlights

Optimal security

Public APIs are de-coupled from the processes performing encryption and singing.

An entity-level security configuration (access control list) is used, limiting users to a minimum set of rights.

Event driven process

The Sign & Encrypt service is event driven, which enables the already mentioned de-coupling of public and private resources.

Events are also used in order to communicate the result of a task and to add its information to the audit log.

Audit logging

All tasks are automatically put in the audit log, created thanks to the used event driven mechanism.

The audit log can be viewed only by users who have sufficient permissions.

Four-eyes principle

Signing can be protected by an additional approval step, requiring a second person to approve the task (four-eyes principle).

In addition, it can be required that the approver authenticates with multi-factor authentication.

Container format

The applied container format is lightweight and easy to parse, which allows it to be implemented even on smaller embedded devices.

It is flexible, in the sense that it may contain more than one firmware image as payload for devices with multiple controllers.

Furthermore, it supports an extendable list of well-selected cipher suites from which an adapting product may choose.

Key import and export

The system allows to import existing keys, thus easing migration to Sign & Encrypt.

If required, the keys can be also exported to avoid vendor lock-in.