Security

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 elements. 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 - especially the RFID interface component:

Config Security Code

When you configure the RFID interface (e.g. when creating a configuration with Autoread Wizard), a unique Config Security Code is generated that serves as a kind of "ID" for the 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.

Don't leave the RFID interface unconfigured when using Autoread

When operated in Autoread mode (i.e. when reading cards autonomously), readers without an RFID interface component - and thus without a Config Security Code - are vulnerable to unauthorized reconfiguration because all configuration methods (besides configuration via the host) are based on Autoread. That's why we highly recommend you always add an RFID interface component, even if factory settings meet your needs. The easiest way is to ensure you have a complete and secure configuration is to use Autoread Wizard.

The RFID interface only remains unconfigured if you develop a custom application with the operation mode APDU, PC/SC, or Low level: In these cases, Autoread is disabled.

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 BEC2/BEC file. Deployable 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 deployable file is exported when you release 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 deployable file from the encrypting reader to the other ones. This measure prevents deployable 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.

Customer key

By default, the key used for end-to-end encryption of deployable BEC2/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 deployable 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 deployable 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.

What to consider when editing a configuration

When you initially release a BALCFG file, it 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 release a new version.

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

Tamper alarm (ACCESS200)

Once your ACCESS200 readers are installed, a tamper alarm will be triggered in the following cases:

• Manipulation on the hardware level.
  This includes, e.g. opening the reader housing.

• Manipulation on the software level via the RFID interface. This includes, e.g. the use of a ConfigCard, an AdrCard, or
  Wireless Upload via NFC.

  The tamper alarm for ConfigCard and Wireless Upload requires firmware 1100 v2.00 or above.

When the alarm is triggered, a notification is generated and sent to the host system if this is supported by the host protocol. It works with OSDP, BRP, and some customer-specific protocols. Further notification processing and forwarding must be defined in the host system application.

Your protocol doesn't support notification delivery? Then you can order a configuration that sends a defined number to the host system when the alarm is triggered.