The BALTECH security concept is designed to provide a maximum of protection against tampering attacks. Here's an overview of the measures we've implemented.

Configuration protection

Reader configuration is one of the most security-critical components. Successful attacks could e.g. result in attackers gaining access to the keys for the project cards or compromising the data returned to the host system. That's why there are strong security measures in place to protect the integrity and confidentiality of your configuration and especially the project settings:

Config Security Code

When you add project settings to a configuration, a unique Config Security Code is generated that serves as a kind of "ID" for your configuration. Readers to which you deploy this configuration won't accept a different configuration anymore. They will only accept a new version of the same configuration as in this case, the Config Security Code remains the same. This behavior prevents unauthorized reconfiguration, e.g. via a tampered ConfigCard.

If you need to deploy a different configuration to a reader, you can remove the Config Security Code by doing a factory reset.

Productive readers without project settings are a security risk

Theoretically, project settings aren't needed if you only want to read a card's serial number (UID). However, without project settings - and thus without a Config Security Code - your readers are vulnerable to unauthorized reconfiguration. That's why we highly recommend deploying project settings to all productive readers.

Configuration updates with rollback prevention

While the Config Security Code prevents readers from accepting different configurations, you can, of course, deploy a newer version of the existing configuration, e.g. if a key has changed or you've found a bug. Rollback prevention ensures that older and potentially insecure versions are rejected by the reader.

This applies to configurations created with ConfigEditor v4.15.00 (released 11 September 2018) or above. To load these configurations, you need Uploader v4.13.00 (released 12 June 2018) or above.

If you do need to make a rollback, please take the last working version and create a new version from it.

End-to-end encryption

BALTECH configurations have 2 file formats: the editable BALCFG file and the deployable BEC file. BEC files are end-to-end encrypted, so the project keys stored in the configuration remain confidential. While all other configuration parameters can be retrieved from a reader for support purposes, the project keys will never be visible.

The BEC file is created when you finalize the configuration. The encryption process, however, doesn't take place on your computer, but on a connected reader. The encryption key is stored on other readers as well, so the configuration can be deployed there. Your computer never stores the key and only serves as a means to transfer the BEC file from the encrypting reader to the other ones. This measure prevents BEC files from being compromised during transmission, e.g. by malware eavesdropping on the connection between your computer and a reader.

For questions about further implementation details, please get in touch.

Diagram: End-to-end encryption of BALTECH BEC files with they key stored on readers

Customer key

By default, the key used for end-to-end encryption of configuration BEC files is the BALTECH default customer key. As a larger customer, you can alternatively order your own customer key. This adds another layer of security in addition to that provided by the Config Security Code.

How it works

When you order your own customer key, it will be stored on all your readers. Your readers will then only accept BEC files (or ConfigCards) created with a reader on which the same customer key is stored.

Compatibility with readers using the BALTECH default customer key

Readers on which the BALTECH default customer key is stored also accept BEC files (or ConfigCards) created with a different customer key. Thus, you can start with the default key and later switch to a customer key if you want, without facing compatibility issues.

Diagram: Readers with a company's own customer key won't accept a configuration encrypted with the BALTECH default customer key or another company's customer key

What to consider when editing a configuration

During finalization, the BALCFG file is linked to the customer key stored on the encrypting reader. Thus, you'll need a reader with the same customer key to later edit the BALCFG file and finalize a new version.

This is a typical source of error, especially if the configuration is maintained by various people (learn more).

BALCFG file finalized on reader with company A's customer key can't be edited and finalized on a reader with a different customer key

Tamper alarm (ACCESS2xx)

Once your ACCESS2xx readers are installed, a tamper alarm will be triggered when the reader is removed from its housing to prevent theft or manipulation on the hardware level.
When the alarm is triggered, a notification is sent to the host system; from there, it's processed and forwarded as defined by the host system application.

Alarm notification depends on protocol

The alarm notification can only be sent if this is supported by the protocol used for the communication between reader and host system. It works with OSDP, BRP, and some customer-specific protocols. Your protocol doesn't support it? Then you can order a configuration that sends a defined number to the host system when the alarm is triggered.