Rockbox Technical Forums
Rockbox Development => Feature Ideas => Topic started by: __builtin on July 26, 2014, 04:25:10 PM
-
This has been asked many times before, but a LONG time ago.
A patch for a password protection feature is here: http://www.rockbox.org/tracker/task/10188 (http://www.rockbox.org/tracker/task/10188), but only supports 4-digit passcodes and is a plugin, meaning that a reboot erases everything.
I am not suggesting an unbreakable security, just something that would take a determined hacker an hour or so to crack, and a layperson out indefinitely.
So, I boiled it down to this:
- password is configured in settings
- a separate program (for host computer) allows the DAP to be unlocked on USB by sending a special unlock key
- unlock key can be generated from settings
- RB (or ROLO) checks for passwords being enabled on boot, in config.cfg and asks for it if it finds it
- passwords are hashed securely (MD5 and SHA1 functions have already been written for RB) and stored in config.cfg
- USB is disabled when at the unlock screen so as to prevent editing of the config.cfg file
- something similar to the iOS delay feature (1 minute, 5 minutes, 15 min, 60 min, 24 hr, lockout)
- when the DAP has become locked out, the unlock program needs to be used to unlock it.
Does anyone besides me see a real need for this? If so, I could write it.
I understand that this goes against some aspects of freedom in that it could disable your hardware forever by accident, and the fact that there are some obvious backdoors around this (on iPod 6G, emCORE allows the data partition to be wiped), but it's better than nothing.
-
You won't get an hour worth of security on most devices because they have an emergency or failsafe USB mode, usually implemented in hardware. Anyone with google and some common sense will be able to remove the lock screen in a couple minutes.
But sure, if you don't mind the feature being easily bypassed on most devices, you could certainly implement it.
-
For this to even be considered a mild deterrent, you would need to completely disable dual-boot, which frankly isn't going to happen.
You have considered the case of the iPod 6G and emCORE, but that actually strikes me as being one of the least obvious workarounds.
The other iPods for instance all have dual-boot, and even if they didn't, there's still Emergency Disk Mode to contend with.
In both those scenarios, an "attacker" could have disk access in a matter of seconds.
Now, one may argue that access to the disk is useless if the data is encrypted...potentially valid, I guess. But I argue that any sufficiently determined attacker is simply going to use this trivially acquired disk access to flash in a binary that reverses the encryption process.
...it is going to be freely available source, after all.
That's the most obvious point of failure, to me. The act of committing such a feature involves giving a potential "attacker" an exact recipe on how to circumvent it.
[Saint]
-
For this to even be considered a mild deterrent, you would need to completely disable dual-boot, which frankly isn't going to happen.
You have considered the case of the iPod 6G and emCORE, but that actually strikes me as being one of the least obvious workarounds.
The other iPods for instance all have dual-boot, and even if they didn't, there's still Emergency Disk Mode to contend with.
In both those scenarios, an "attacker" could have disk access in a matter of seconds.
Now, one may argue that access to the disk is useless if the data is encrypted...potentially valid, I guess. But I argue that any sufficiently determined attacker is simply going to use this trivially acquired disk access to flash in a binary that reverses the encryption process.
...it is going to be freely available source, after all.
That's the most obvious point of failure, to me. The act of committing such a feature involves giving a potential "attacker" an exact recipe on how to circumvent it.
[Saint]
Sooo... No hope. :(
Maybe it would work against 5-year-olds, though, and might be worth adding still. ;)