So at 4am this morning I completed a first round of analysis, got some sleep and got back to work however somethings been itching in the back of my head, why the 120 character as part of the beacon? Why not keep it a simple tight hash of the individual and have the hash elsewhere? It would be easier to send, manage and less likely to disclose an individual user.
The answer was evident in my last post- there needs to be integrity and an ease of quick contact in the event of discovery, therefore a symmetrically encrypted set of relevant parameters is getting sent. This deduction is further reinforced with the statement that “ Any attempt to decrypt contact data is an offence.” So this evening has been a bit of a review of what the msg value is and what it means.
Since my post, I noticed the value has recently changed, which would suggest additional security controls preventing replay attacks and constant tracking by regular updating the displayed value. This is awesome, but I’m still perplexed by how the msg value is created.
An overview of cryptography
As mentioned, it looks like the msg value referenced in my previous post appears to be encrypted. Similar analysis on the Singapore version of the app suggested the encryption was using symmetric key. I deduct this might also be in place based on the operational requirements, value lengths and a very brief glance at the source code. The value that would be encrypted would be some combination of the following values:
- Post Code
- Age
- Name (or alias)
- Phone Number
- Device ID (Maybe)
Symmetric key cryptography involves using the same key to encrypt and decrypt data.
As a government system, it is likely that this is using AES 128,192 or 256 bit encryption and the key is located server side which I believe is AES 256.
Risk 1: Key management
So I’m working through if it is a symmetric key system and if keys are stored server side, but lets assume we’re working on AES256 symmetric keys.
- If key material is server side and never disclosed to the end user, Is there a universal AES256 key, a per device/user AES256 key, does it rotate, and what operational difficulty does this present? If a master key is in use and the key is disclosed, will this disclose all records especially from bluetooth devices doing open collection right now?
- If the private key is stored with the client and only disclosed when required, does this practically assist likely infected people who have not disclosed their client key (making this scenario unlikely).
- Will it be possible to disclose the key if its stored on the phone (too late tonight, and I need sleep this evening).
- What is the structure of the msg value, does it include a name and phone number that can be disclosed should the above scenario be realised? and is it possible to create a malicious MSG value based on a request to the server (unlikely).
Ideally, both of these have been factored in somewhere however they were not discussed in the privacy impact assessment.
Risk 2: Deriving the private key from known plaintext or at least mapping out some content
The issue with some symmetric key cryptography is you need the following scenarios:
- The algorithm, the key and the plaintext
- The algorithm, the key and the cipher
However other options exist.
Theoretically, we can conduct a brute force attack against a private key which is largely how WPA-PSK cracking works. However AES256 is a little more resistant to brute force using current tech, and we’d be here for a few thousand years before being able to crack it (we’re talking a few centuries with decent compute power).
Given we can roughly deduct the plaintext and know the ciphertext, I went to some efforts this evening looking to structure the plaintext and encrypt AES 256 and multiple cipher modes to see if I could get the structure and content of the encrypted data to no avail… however I dare say there are additional parameters added in such as time or another possibly another value not known to the client.
Side note: an observation of reliability
One thing I have noted, and this is a common issue with some bluetooth, is the reliability of the technology; despite multiple interactions and broadcasts, only about 20% of the packets appear to be logged in the local database on the phone. Whilst this does seem like “not quite enough” any prolonged contact (more than a minute or two) will be logged which is probably enough.
Still looks like theres no real major issues
The identification today of the rotating value is a positive; this will undermine or reduce the ability for tracking individual users, conducting injection and will raise the integrity of the app, however the real issue is that I am yet to observe any considerations on the crypto implementation by any academic analysis or the privacy assessment, which will present a remote risk under very specific circumstances.
Once again, I have not decrypted data, reviewed code or interacted with the server side application beyond normal interaction.
