Security
The check-in platform implements two specific security features;
-
Authentication and authorization ensuring only authorized users are able to access the check-in platform functionality.
-
EBT security mechanisms to ensure EBT lock during travels. (Additionally, there is a physical button that needs to be pressed to activate Bluetooth functionality. If pressed it is discoverable for only 30 seconds.)
Authentication and authorization
Authentication is for two different purposes:
-
making sure we are communicating with the correct third party client
-
making sure we are communicating with the correct user of the third party client
The check-in platform has been designed to manage users from different clients and partners. Clients can be authenticated using several different means of authentication. After authenticating an access token will be issued, which must be included for authorizing each subsequent API call. Additionally, each API call must include a valid key unique for each partner as issued by BagID.
As the API should be available to different types of clients, we will provide different ways for the trusted third party clients to authenticate themselves.
Federated authentication
Using federated authentication the check-in platform will verify signed authentication tokens from trusted partners and issue a BagID API token to use for all further communication. This requires users to authenticate in the partners platform, ie through airline loyalty program or similar.
Attestation
App attestation is a security technique that verifies the integrity and authenticity of a mobile app, ensuring it is unmodified and running on a trusted device before accessing server resources. It protects against fraud, repackaged apps, and automated threats by validating the app’s signature through hardware-backed cryptographic checks, commonly provided by Apple’s App Attest and Google’s Play Integrity API.
The check-in platform is configured to use such attestation to verify the source of the authentication request is valid. We require the client to get a nonce from the backend, and along with a client key (identifying the client) and the attestation from the app store (Apple or Google), it will be possible to verify that the client is who he claims to be.
Client id and key
If the client is not an app from an app store, we will provide them with a unique key and a secret. This is provided as a username/password to obtain a signed token.
Note: this should only be used by clients that are not distributed or public, as security relies on the private key issued.
EBT security implementation
Electronic bag tags accepts updates only from authorized airline or partner tooling. IATA-oriented guidance calls for a defined security mechanism, so arbitrary Bluetooth peers cannot change what the tag shows.
Many EBTs have no real-time clock, so firmware cannot enforce X.509 validity periods in the usual way. The tag still needs to cryptographically verify what the phone presents. We will be using a nonce and backend intervention to ensure only valid sessions with the EBT.
Layer 1 — identity (CA and client certificate)
A root of trust (ECDSA public key) lives in EBT firmware. The backend generates an X.509 client certificate signed by the Root CA private key (held in KMS/HSM) and delivers it to the app over the authenticated HTTP session. The certificate endpoint requires a session backed by platform attestation (App Attest / Key Attestation) or federated identity — the certificate’s trust is bounded by the session that requested it. No client-side key generation or CSR is required.
The certificate bridges online trust to the offline BLE channel. The EBT verifies the certificate using the embedded root public key, confirming the backend endorsed this app installation. A random or unauthorized BLE client without a valid certificate is rejected before the firmware generates a nonce.
Layer 2 — integrity (centralized transaction authorization)
The backend is the source of truth for whether the current session may act on a given EBT. An active tag is associated (locked) with a journey. The backend only issues transaction tokens for EBTs in the current user’s active session/journey or with no current lock. A caller who is not allowed (wrong user, journey locked, lost mode, etc.) does not receive a token. The backend also enforces certificate validity and revocation at token-issuance time, compensating for the EBT’s inability to check certificate expiry (NO_ASN_TIME).
The EBT firmware generates a random nonce upon connection. The backend signs SHA256(GUID || nonce) with the Root CA private key to produce the transaction token. The EBT verifies this token with the embedded Root CA public key, confirming: (a) the backend authorized the write, (b) the authorization is for this specific tag (GUID), and (c) the authorization is for this specific session (nonce).
Journey lock details
The journey lock is a feature allowing users to use their BagIDs in different channels without proving their full identity, which delivers flexibility while providing required security. While assisting on layer 2 security above, journey lock acts as a write protection lock and proof of custody. When the EBT is on a journey, it should be write-protected, unless the passenger can prove their ownership. In situations where the EBT may be used in different channels (BagID app, Airline apps etc.), switching between channels is possible by proving ownership through this mechanism.
To enforce the lock we require the client to notify the check-in platform when transfer to the EBT is completed using the issued transfer token. The same goes for clearing and releasing the EBT lock.
If an EBT is locked to a journey, client needs to ask for custody proof (PNR reference and surname of journey which is locking the EBT). The device will be unlocked when proof is provided, and only a successful baggage transfer to the EBT will lock the device again.
The EBT owners still have the option of adding their EBTs to their account and managing them, gaining access to features like ‘lost mode’ giving them the ability to block anyone else from using the EBT after that. Using this feature is optional.
Journey lock will also have an expiry period where it is automatically removed after a pre-defined and configurable number of hours, making it invisible from user experience in normal use cases. BagID can change the exact number of hours without further notice.
It is important to mention that the EBT can be used in any channel by anyone if there is no active journey lock and lost mode is disabled, even if it is assigned to a user account.