Traditional physical keys vulnerable to cope, loss or misuse. Digital access credentials require a different security approach. The approach protects the credential itself and the communication channel transmitting the credentials.<\/p>\n\n\n\n
With Aipix-based BLE access control device, BLE tokens are transmitted through secure communication channels using banking-grade cryptographic algorithms. The solution encrypts all exchanged data, helping prevent interception, modification, or unauthorized reuse of digital credentials.<\/p>\n\n\n\n
Users can configure the preferred automatic door opening distance according to their needs. The system also verifies the actual distance between the smartphone and the BLE controller before granting access.<\/p>\n\n\n\n
This additional validation helps reduce the risk of unauthorized activation attempts from outside the permitted area. Also it ensures that access is provided only when the authorized device is physically close to the access point.<\/p>\n\n\n\n
How does the BLE-based solution provide protection against unauthorized access? Justification of the cryptographic strength of the BLE access agreement scheme<\/h2>\n\n\n\n
The access authorization scheme between the mobile application and the BLE controller based on protocol v3. It is built on standard cryptographic primitives (AES-128, SHA-256, HMAC-SHA256) and their correct combination. The conducted analysis did not reveal any design flaws that would allow an attacker controlling the radio channel to open the controller without possessing a valid key.<\/p>\n\n\n\n
The scheme will remain secure exactly as long as AES-128 and SHA-256 remain secure. Since these are cryptographic standards with many years of public analysis history, for which no attacks known that are practically more effective than exhaustive search.<\/p>\n\n\n\n
Key quantitative indicators: Distinctive advantages of the scheme:<\/p>\n\n\n\n The following attacker model assumed:<\/p>\n\n\n\n The attacker\u2019s objectives considered to be:<\/p>\n\n\n\n An attacker cannot unlock the controller without obtaining the valid \u201cencrypted token\u2013client key\u201d pair for the specific controller and the relevant time period. The probability of success remains no higher than n \u00b7 2\u207b\u2076\u2074<\/strong>, where n<\/strong> represents the number of attempts made by the attacker.<\/p>\n\n\n\n Recovery of the master key, client key, or access token contents from radio exchange data would require breaking the security of AES-128, SHA-256, or HMAC-SHA256<\/strong>.<\/p>\n\n\n\n The architectural solution from which most of the scheme\u2019s properties follow is that it calculates the client key as an authentication tag (HMAC) of the access token contents using the master key.<\/p>\n\n\n\n The same value serves both as the authentication code protecting the token integrity and as the secret through which the application proves its access rights. This leads to the following properties:<\/p>\n\n\n\n Token integrity is verified at no additional cost.<\/strong> The application transmits the encrypted token in plain form. Changing even a single bit of the token results, after decryption, in different content, and therefore in a different client key and a signature mismatch. It does not require a separate token integrity check as already performed as part of the response signature verification. This eliminates an entire class of implementation errors related to the order of authentication code verification and decryption operations.<\/p>\n\n\n\n The application cannot modify its own permissions.<\/strong> The token contents are unknown to the application; it only receives the ciphertext and the client key. To set an administrator flag or extend the validity period, it would be necessary to create new token contents and calculate an authentication tag for them using the master key, which is not available to the application. Brute-forcing ciphertext is useless: the corresponding client key would remain unknown. Privilege escalation is reduced to breaking HMAC-SHA256.<\/p>\n\n\n\n <\/p>\n\n\n\n An attacker who does not know the client key must provide a valid signature for a request generated by the controller and unknown in advance.<\/p>\n\n\n\n If an algorithm existed that could produce such a forgery with a probability significantly higher than 2\u207b\u2076\u2074<\/strong>, the hackers could use it to construct either a distinguisher for HMAC-SHA256 as a pseudorandom function or an algorithm for finding partial preimages of SHA-256. For both primitives, researchers have found no attacks more efficient than brute force. No known attack against HMAC-SHA256 exploits its internal structure to recover the key faster than exhaustive search. SHA-256 also remains resistant to preimage attacks: existing results affect only significantly reduced-round versions and do not apply to the full algorithm.<\/p>\n\n\n\n It is important that the client key is the output of HMAC-SHA256, meaning it consists of uniformly distributed 256 bits rather than being a password or a value from a limited alphabet. Dictionary and structural attacks are therefore impossible by design.<\/p>\n\n\n\n The signature covers the entire response together with the request, and the request contains a random 64-bit value generated by the controller anew for each interaction. A response recorded by an attacker is valid only for a single value of this number and therefore cannot be replayed.<\/p>\n\n\n\n The request contains the public identifier of the controller\u2019s master key, and the system includes this identifier in the signed data. This cryptographically binds the response to the intended key: if an attacker captures a response from one controller, another controller with a different identifier will reject it. <\/p>\n\n\n\n The signature can only be verified by the party that holds the master key, because the system derives the client key from the encrypted token using this master key.<\/p>\n\n\n\n The signature is calculated as the first 8 bytes of the hash of the intermediate value.<\/p>\n\n\n\n If the signature were a prefix of the intermediate value itself, publishing the signature would reveal 64 bits of the future session key, reducing its security and creating a connection between public and secret material. Intermediate hashing provides cryptographic domain separation: recovering the session secret from the signature is impossible except by finding a partial preimage of SHA-256.<\/p>\n\n\n\n As a result, from a single HMAC computation, the scheme derives two values that are independent in terms of security: a public proof of key ownership and a full 256-bit session secret.<\/p>\n\n\n\n Assume that an attacker has extracted the pair \u201cencrypted token \u2014 client key\u201d from the phone. The attacker gains the ability to open the same controller with the same permissions and within the same time limits as the legitimate owner.<\/p>\n\n\n\n A leak only affects the permissions already granted to the compromised user, and the access automatically ends once the key expires.<\/p>\n\n\n\n During reverse connection, the phone responds to requests from any connected device, while during direct connection, an attacker can impersonate the controller. In both cases, the attacker can submit chosen requests and collect the corresponding responses.<\/p>\n\n\n\n However, this does not provide the attacker with any advantage. Each response reveals 64 bits of the function output for a chosen input. Recovering the 256-bit client key from such observations is a standard key-recovery problem for a pseudorandom function under chosen-input attacks, and HMAC-SHA256 provides no known solution better than exhaustive search.<\/p>\n\n\n\n Even two observations are sufficient for a candidate and uniquely determined, but verifying each candidate requires a HMAC computation, and the number of possible candidates remains 2\u00b2\u2075\u2076.<\/p>\n\n\n\n The scheme relies exclusively on AES-128, SHA-256, and HMAC-SHA256 \u2014 primitives standardized in FIPS 197, FIPS 180-4, and RFC 2104, with many years of public cryptanalytic history and thoroughly tested implementations.<\/p>\n\n\n\n This is a significant advantage and deserves separate emphasis. The overwhelming majority of practical failures in access control systems are not caused by weaknesses in cryptographic primitives, but by weak or vulnerable schemes for combining and applying them.<\/p>\n\n\n\n The quantitative analysis shows that all critical security parameters provide a substantial margin over practical attack thresholds. The master key provides approximately 190-bit security, the derived encryption key preserves approximately 127 bits of entropy, online forgery requires infeasible computational effort, and the probability of random number reuse remains negligible even under large numbers of sessions.<\/p>\n\n\n\n The cryptographic core of the scheme is correctly designed, and its security is ensured by a consistent combination of factors:<\/p>\n\n\n\n Modern access control is no longer only about opening doors. It is about protecting identities, securing communication channels, and creating reliable digital infrastructure.<\/p>\n\n\n\n Aipix-based BLE access control combines encrypted data transmission, protected digital credentials, proximity verification, and privacy-conscious design to provide a secure alternative to traditional access methods.<\/p>\n\n\n\n By balancing security, convenience, and regulatory requirements, BLE technology helps telecom operators, service providers, and organizations build scalable smart access solutions without compromising cybersecurity. At the same time, the BLE controller is just one of the available equipment options for organizing access point. The decision whether to implement it or not depends on the requirements and specifics of client’s project. <\/p>\n\n\n\n Ready to open up new opportunities for your telecom business with secured contactless BLE-access control and beyond? Contact us and we will explore together the smart access control solution organisation.<\/p>\n\n\n\n
<\/p>\n\n\n\nIndicator<\/strong><\/td> Value<\/strong><\/td> Comment<\/strong><\/strong><\/td><\/tr> Master key security strength<\/td> \u2248 190 bits<\/td> With a practical security threshold of 128 bits<\/td><\/tr> Reliability of the Derived Encryption Key<\/td> \u2248 127 out of 128 bits<\/td> Losses during derivation are negligible<\/td><\/tr> Probability of response forgery<\/td> 2\u207b\u2076\u2074 per attempt<\/td> <\/td><\/tr> Offline brute-force attack<\/td> Impossible<\/td> <\/td><\/tr> Expected time to brute-force the signature<\/td> > 10\u00b9\u2070 years<\/td> At 10 attempts per second<\/td><\/tr> Probability of request repetition during the service life<\/td> \u2248 3 \u00b7 10\u207b\u2078<\/td> With 10\u2076 unlock operations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n \n
What is threat model<\/strong> for BLE access control solutions?<\/h3>\n\n\n\n
\n
\n
What Consolidates Security Strength Statement<\/strong> of BLE access?<\/h3>\n\n\n\n
What the BLE access security strength is based <\/strong>on?<\/h2>\n\n\n\n
The Client Key Is the Authentication Tag of the Token Itself<\/strong><\/h3>\n\n\n\n
Impossibility of Response Forgery<\/strong><\/h3>\n\n\n\n
![\"BLE](\"https:\/\/aipix.ai\/blog\/wp-content\/uploads\/2026\/08\/BLE-access-secyrity-client-and-master-key-1024x683.webp\")
<\/figure>\n\n\n\nReplay Protection<\/strong><\/h3>\n\n\n\n
Binding to a Specific Controller<\/strong><\/h3>\n\n\n\n
Separation of the Signature and the Session Key<\/strong><\/h3>\n\n\n\n
Localization of Application Compromise Consequences<\/strong><\/h3>\n\n\n\n
What the attacker does not obtain<\/strong><\/td> Why<\/strong><\/td><\/tr> Master key<\/td> The client key is an output of HMAC using the master key; obtaining the master key is equivalent to breaking HMAC-SHA256 as a one-way function<\/td><\/tr> Token contents<\/td> The token remains encrypted using a key derived from the master key<\/td><\/tr> Permission extension or renewal<\/td> Access boundaries and permissions are fixed inside the token and verified by the controller; modification requires the master key<\/td><\/tr> Access to other controllers<\/td> Master keys are unique for each device<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Resistance to Adaptive Queries<\/strong><\/h3>\n\n\n\n
Absence of Custom Cryptography<\/strong><\/h3>\n\n\n\n
Quantitative Assessments<\/strong><\/h3>\n\n\n\n
Parameter<\/strong><\/td> Calculation \/ Evaluation<\/strong><\/td> Result<\/strong><\/td><\/tr> Master key<\/strong><\/td> 32 characters from an alphabet with 62 possible symbols<\/td> \u2248 190.5 bits of entropy<\/td><\/tr> Derived encryption key<\/strong><\/td> The key derivation function compresses 190 bits into 128 bits<\/td> \u2248 127 bits of entropy out of 128 possible<\/td><\/tr> Entropy preservation mechanism<\/strong><\/td> The permutation of nibbles in the second half of the master key combines a \u201clow-entropy\u201d nibble of one character with a \u201chigh-entropy\u201d nibble of another character<\/td> Each resulting nibble is formed by combining two statistically different components<\/td><\/tr> Online forgery probability<\/strong><\/td> Probability of successful signature forgery per attempt<\/td> 2\u207b\u2076\u2074 per attempt<\/td><\/tr> Expected time to successful forgery<\/strong><\/td> At 10 attempts per second<\/td> > 10\u00b9\u2070 years<\/td><\/tr> Random number collision probability<\/strong><\/td> Approximately q\u00b2\/2\u2076\u2075 for q sessions<\/td> For 10\u2076 controller openings during its lifetime: \u2248 3 \u00d7 10\u207b\u2078<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Cryptographic strength of the BLE access agreement summary <\/strong><\/h2>\n\n\n\n
\n
BLE device as a foundation of contactless secure access<\/strong> and market opportunities<\/h2>\n\n\n\n