As we know, the international travel edition, there is the feature that after 20 total/cumulative failed attempts that the device is wiped, and there is a timeout after 3 failed PIN attempts. This prevents brute forcing of the primary PIN and allows disclosure of the secondary PIN, whilst also stopping accidental destruction of the device.
However, the fact that standard edition lacks this seems like some sort of a lapse in security?
It would be nice if you could have this in the standard edition, without having to make the sacrifices that come with the ITE like no encryption and less features overall. Say, 100 total cumulative pin failures? If 20 is deemed as a high enough number in the ITE, I do not see why this feature would not be useful for all editions.
Am I misreading the documentation? Or is this something unique to the ITE, and in theory an attacker is able to brute force the secondary profile on the standard firmware? As in, they can enter 9 attempts of guessing the secondary profile, then enter a known profile, and reset the 10 attempts to guess 9 more times?
Is there not a countermeasure for this? This effectively means the only way for plausible deniability would be to not have encryption and have less features.
This is something unique to the ITE. The standard edition provides no protection of the secondary profile if you have access to the primary and vice versa. The profiles are just a way of organizing your accounts for say personal and work use, but this is still for a single user. The profiles are not intended to be used for say user1 and user2 on the same device. It is a single user that uses both profiles.
Right, there is no way to have both plausible deniability and encryption. The ITE provides very limited features and plausible deniability. The Standard edition provides full features and no plausible deniability.
Hence, My reason for this post. I would like to request this feature if this is possible.
If there is encryption, on a key how would adding a plausible deniability profile be impossible/infeasible? Surly if the key can not be read, and is encrypted, the sector containing the second profile will be indistinguishable from random noise, hence adding brute force protection for the second profile would have absolutely no downside?
I absolutely love the ONLYKEY but this seems like a tremendous lapse in development, that the only use case for plausible deniability is on an unencrypted version of the key?
The juxt of my question is, If it’s possible to have plausible deniability on an unencrypted ITE key, what’s the rationale behind not having it on the encrypted version? There is surly no way to prove the existence of a second profile in either case; and allowing brute forcing on the encrypted version?
Kind regards
Rq
Edit- I am assuming the reason is that the encrypted partition that is unlocked with the PIN contains both user profiles within it, and not that each PIN decrypts a separate partition?
An idea I could think of would be that the counter of total cumulative failed PIN attempts is only reset upon successful login of the second/hidden profile. This would effectively destroy brute force attempts of the hidden profile by limiting the total number of failed attempts (like on the ITE), whilst still allowing this total number of incorrect attempts to be reset, simply by re entering the other profile key and resting the counter.
Scenario-
User discloses dummy PIN
Adversary attempts to discover a second profile by brute forcing
Adversary uses the known method of using 9 PIN guesses, followed by the known dummy PIN
Adversary then successfully unlocks with the known dummy PIN and resets the normal 10 PIN limit
But, since the dummy (or real) profile was opened, a global counter keeps track of the number of total unsuccessful PIN attempts overall since the last time the other profile was opened
Adversary repeats step 3, but after 100 failed total attempts, the key is wiped, as the other profile that is unknown has not been opened for 100 failed attempts (or <100, i do not kno)
If the adversary stops and user gets the key back, they can reset this 100 fail wipe limit by unlocking with the key the adversary was trying ot discover.
Would this be difficult to impliment?
I’m very happy with onlykey but think this would be a good idea.
I will leave this thread open if there are others interested in this feature. We typically only implement the features used by the most users so there would need to be broad interest. Also this feature has the risk of accidentally wiping your profile, and that if an adversary was able to unlock one profile and they had the backup passphrase they could backup the device. The backup would contain both profiles (unless another feature was implemented to prevent that).