Reply
Thread Tools
Posts: 56 | Thanked: 26 times | Joined on Aug 2010
#1
I think this has been discussed before, but I want to bring it up again since I saw this tonight:

http://yro.slashdot.org/story/11/01/...-mdash-Or-Else

Needless to say the vast majority of the discussion is iOS or Android, but what about us? We have more power over our devices than they do, so what can we do to make our devices REALLY secure?

Or can we? Being that we're talking about flash memory here, I have some concerns about leftover data still being in there even after being "deleted". I'm not talking about a filesystem delete where it just flags a bunch of inodes as unused, I'm talking about where even if you do a supposed low-level wipe that wear-levelling and such will still preserve the data, unlike on a disk.

So to summarize, I'm fully aware (as should all of you be) that security is always layered. The way I see it, the layers are:

1. App level: how do you make sure that, once you save them, app data from texts and the web browser are wiped?

2. System Password level: it seems to me you can overcome an installed password just by accessing the eMMC in mass storage mode, just like you would with any other drive--you don't even need special forensic tools. Is it worth even setting a password just to defeat n00b thieves and the curious?

3. Full Disk Encryption: the ultimate achievable level, IMHO, but subject to the flash limitations I said above. If that can be overcome, it seems it ought to be trivial to use whole-disk encryption. Has anyone done it? Has anyohe done it on Android?

Thanks, Mike
 

The Following User Says Thank You to storkus For This Useful Post:
Posts: 303 | Thanked: 146 times | Joined on Aug 2009
#2
I don't know how someone can obtain the data from flash that is saved in special areas for wear leveling purposes. I mean, is there a way to get this data, without actually opening the flash chip, and manually tap the traces inside? This is very expensive and complicated stuff, I doubt many people have the resources to do it.
 
Posts: 5 | Thanked: 0 times | Joined on Feb 2010 @ London
#3
I too read the same article (actually from Ars) and had the same thoughts (even though I'm in the not-quite-a-policed-state-yet UK). I see that TrueCrypt is available but it is an older version (6.3 as opposed to the current 7.0 on other platforms. Has anyone used it? Is it viable to encrypt various parts of the device?
 
Posts: 115 | Thanked: 342 times | Joined on Dec 2010
#4
App level: how do you make sure that, once you save them, app data from texts and the web browser are wiped?]
1. Maybe the tool shred can help. But only maybe. The manpage tells you more about that issue (Journaling file systems). When you are using encryption, this shouldn't be that important.

...it seems to me you can overcome an installed password just by accessing the eMMC in mass storage mode...
What password do you mean? What I do know is that you can't rely on the lock code or any other password solution, which instead of encryping the data only "protects" it with some GUI dialog.

Full Disk Encryption... well. I think it is nearly impossible or very very hard. Of course, I could be wrong, but I think nobody has done it yet.

Has anyone used it? Is it viable to encrypt various parts of the device?
Yes, it is possible. Version 7 runs too, but you have to compile it yourself. So, this is nothing for the end/average user at the moment.
 
Posts: 842 | Thanked: 1,197 times | Joined on May 2010
#5
It seems like we could do a couple of things:
1. Make the /home/ partition incompatible with the normal OS - Either an excrypted FS, or just something other than EXT2/3.
2. Put a good lock key on the software, and have it auto-lock after a couple of minutes.

Now, if some police officer tries to get into it, they have to contend with the key. Sure, its only 5 digits, but it'd take quite a while.
Provided they try going further than that, they'd need to get into the OS - To do this, they'd have to reflash. If they do, they will try flashing the rootfs. If done right, it won't boot, as it can't mount /home/.
If they flash the eMMC too... problem -also- solved; all data will be wiped.

Think simple here.
__________________
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
 
WereCatf's Avatar
Posts: 255 | Thanked: 160 times | Joined on Oct 2010 @ Finland
#6
Originally Posted by Radu View Post
I don't know how someone can obtain the data from flash that is saved in special areas for wear leveling purposes. I mean, is there a way to get this data, without actually opening the flash chip, and manually tap the traces inside? This is very expensive and complicated stuff, I doubt many people have the resources to do it.
It depends on the flash technology in use. Some controller chips do allow you to bypass them and give direct access to the flash, whereas in some cases the wear-leveling et al are actually done by the OS.

Though of course if there is no way to bypass the controller and directly access the flash chips then it would indeed be really, really expensive, not to mention the hardware would be unusable afterwards.
__________________
HAND, n.
A singular instrument worn at the end of the human arm and commonly thrust into somebody's pocket.
 
WereCatf's Avatar
Posts: 255 | Thanked: 160 times | Joined on Oct 2010 @ Finland
#7
Originally Posted by NIN101 View Post
1. Maybe the tool shred can help.
It can't. This is exactly because of the wear-leveling mechanism: the controller tries to balance all writes so that all physical blocks have around the same amount of writes happened to them and this is done by mapping a physical block to a virtual one. When the OS tries to write block #15, it might actually be writing to physical block #3.

Full Disk Encryption... well. I think it is nearly impossible or very very hard. Of course, I could be wrong, but I think nobody has done it yet.
It would be possible, but would require some tinkering around in Maemo OS. Basically, the directory /home/user needs to be encrypted and this could be solved by creating a, let's say, 1 gigabyte file on MMC. Then set up a loopback device pointing to that file, make an encrypted filesystem on it, and mount it on /home/user. The problem is obviously that this would have to happen before 'user' logs in, ie. so early in the boot process that no application yet runs as 'user'.
__________________
HAND, n.
A singular instrument worn at the end of the human arm and commonly thrust into somebody's pocket.
 
WereCatf's Avatar
Posts: 255 | Thanked: 160 times | Joined on Oct 2010 @ Finland
#8
Originally Posted by storkus View Post
1. App level: how do you make sure that, once you save them, app data from texts and the web browser are wiped?
Basically, it must be encrypted at all times, there is no way to ensure that the data is actually gone if you delete it. (Well, except for writing random stuff on all the available free space every time you delete something. But that's not really a feasible alternative.)

2. System Password level: it seems to me you can overcome an installed password just by accessing the eMMC in mass storage mode, just like you would with any other drive--you don't even need special forensic tools. Is it worth even setting a password just to defeat n00b thieves and the curious?
Browser data and such reside on /home/user which can't be accessed in mass-storage mode. So, a password would protect very simple tampering. It wouldn't protect ~/MyDocs though.

3. Full Disk Encryption: the ultimate achievable level, IMHO, but subject to the flash limitations I said above. If that can be overcome, it seems it ought to be trivial to use whole-disk encryption. Has anyone done it? Has anyohe done it on Android?
Full-disk encryption is infeasible. It would require heavy modifications to the whole boot-up process and kernel. Encrypting just the home directory is a much better approach and can be done as I posted above. There is one caveat to such though: it consumer slightly more CPU-time thus eating into battery, and it wears out the flash chips faster as there's more data to write and more often.
__________________
HAND, n.
A singular instrument worn at the end of the human arm and commonly thrust into somebody's pocket.
 
Posts: 115 | Thanked: 342 times | Joined on Dec 2010
#9
It can't. This is exactly because of the wear-leveling mechanism: the controller tries to balance all writes so that all physical blocks have around the same amount of writes happened to them and this is done by mapping a physical block to a virtual one. When the OS tries to write block #15, it might actually be writing to physical block #3.
Thx, I didn't knew that. Very interesting.


It would be possible, but would require some tinkering around in Maemo OS
And then you say this:

Full-disk encryption is infeasible. It would require heavy modifications to the whole boot-up process and kernel.
And i agree.

My understanding of FDE is, that you encrypt everything (expect of the /boot/ partition), not just a partition or even with loop back interfaces. And this would be very tricky as you have said.

Furthermore, there is something with loop back interfaces on the N900. A simple one, mounted with -o loop is kinda slow. My device even rebooted always when I tried to set up a chroot with this simple loop. To have a more performant, one should use dmlosetup, with the dm-mod and dm-loop kernel modules like Easy Debian does.
Of course it should be the problem of the crypto program you use.


Sure, its only 5 digits, but it'd take quite a while.
33 seconds on mine. Not longer than 2 minutes on everyones I would say. But of course it depends on the hardware they have. And we can say without any doubt, that they have access to good hardware lol.

1. Make the /home/ partition incompatible with the normal OS - Either an excrypted FS, or just something other than EXT2/3.
This isn't a protection my friend.

Last edited by NIN101; 2011-01-21 at 15:27.
 
Posts: 701 | Thanked: 585 times | Joined on Sep 2010 @ London, England
#10
Originally Posted by WereCatf View Post
Browser data and such reside on /home/user which can't be accessed in mass-storage mode. So, a password would protect very simple tampering. It wouldn't protect ~/MyDocs though.
Normally true, but if you boot the rescue kernel you can access the whole of the eMMC in mass-storage mode.
 
Reply


 
Forum Jump


All times are GMT. The time now is 15:56.