Notices


Reply
Thread Tools
Posts: 451 | Thanked: 334 times | Joined on Sep 2009
#21
Originally Posted by jebba View Post
I haven't really used this on my N900 except a month ago or so and just that "it works". I do use something similar on my laptop for years for the reasons you describe above.
I've been using an encrypted partition ever since Jebba published his cryptsetup and modified kernel.
On my SD card, I have a tiny vfat partition for when I need to reflash (because of other reasons than encryption). The rest of the 16Gb I have in a separate encrypted partition... I'm using it all the time, no probs whatsoever.

All the pics etc. taken with the phone go there etc. and of course all data...

In my opinion this is a must, if you lose your phone or it gets stolen, it's painful, but at least your data is gonna be safe and unuseable.
 
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#22
Originally Posted by 白い熊 View Post
I've been using an encrypted partition ever since Jebba published his cryptsetup and modified kernel.
On my SD card, I have a tiny vfat partition for when I need to reflash (because of other reasons than encryption). The rest of the 16Gb I have in a separate encrypted partition... I'm using it all the time, no probs whatsoever.

All the pics etc. taken with the phone go there etc. and of course all data...

In my opinion this is a must, if you lose your phone or it gets stolen, it's painful, but at least your data is gonna be safe and unuseable.
@白い熊

1) So you've only encrypted the SD card. The eMMC disk is still unencrypted?

2) When and how do you enter the password for the encrypted partition?
 
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#23
Originally Posted by Joorin View Post
So, you're thinking about "plausible deniability"? (...)

I understand the need in that situation, but it's not related to actually finding out what's stored on the device.
If you don't know whether it is there or not, it would be harder to try to find out what's stored.

Example:
Attacker looking for photos taken by N900.

Situation A
Attacker finds a folder with a few encrypted files, each ranging from 800KB to 1.2MB

Situation B
Attacker finds only a file with a 1GB encrypted content. Further studies of this file shows that the data written there looks a lot like ramdom garbage.

Isn't it clear what situation is safer?





See above.[/QUOTE]
 
Posts: 726 | Thanked: 345 times | Joined on Apr 2010 @ Sweden
#24
Originally Posted by soeiro View Post
If you don't know whether it is there or not, it would be harder to try to find out what's stored.

Example:
Attacker looking for photos taken by N900.

Situation A
Attacker finds a folder with a few encrypted files, each ranging from 800KB to 1.2MB

Situation B
Attacker finds only a file with a 1GB encrypted content. Further studies of this file shows that the data written there looks a lot like ramdom garbage.

Isn't it clear what situation is safer?





See above.
[/QUOTE]

I'm only talking about encrypted file systems and not files encrypted one by one. Situation A has, as far as I know, never been mentioned by me (apart form a suggestion for encryption of separate files before venturing into FS land).
 
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#25
Originally Posted by Joorin View Post
I'm only talking about encrypted file systems and not files encrypted one by one. Situation A has, as far as I know, never been mentioned by me (apart form a suggestion for encryption of separate files before venturing into FS land).
Ok. I thought this discussion was following the method of generating on big file with /dev/ramdom and using it as a container for encrypted files, mounted as a loopback device. If the original file was created with all zeros, for example, an attacker could know (or guess) the parts of the filesystem where there was actual encrypted data on.

Last edited by soeiro; 2010-05-26 at 21:53.
 
Posts: 451 | Thanked: 334 times | Joined on Sep 2009
#26
Originally Posted by soeiro View Post
1) So you've only encrypted the SD card. The eMMC disk is still unencrypted?
Yep, I put all the data on the encrypted SD, and basically use the eMMC for useless storage. I was thinking about encrypting the eMMC for a while but didn't do it as per the answer to the point below...

The DCIM folder etc. I also store on the encrypted SD and just created eMMC symlinks to it.
2) When and how do you enter the password for the encrypted partition?
After the device boots, the first thing I do is open the terminal and cryptmount... the SD.

If you'd want to encrypt the eMMC and preserve home on it etc. you'd have to mess with creating an initrd that would ask for password on boot etc. There's all kinds of potential problems where your device (well, at least mine) would hang and you'd have to reflash before you'd get it right, that I decided - to hell with it, not worth the trouble, but I think it could be done.

Jebba's kernel had a framebuffer enabled, so you'd be able to see prompts for the pass and enter it. Now however I'm using Titan's overclocking kernel, and would have to mess with recompiling and the initrd... No go for me.

If you do it, let us know here...
 

The Following User Says Thank You to 白い熊 For This Useful Post:
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#27
Originally Posted by 白い熊 View Post
After the device boots, the first thing I do is open the terminal and cryptmount... the SD.
Ok.

Originally Posted by 白い熊 View Post
Jebba's kernel had a framebuffer enabled, so you'd be able to see prompts for the pass and enter it. Now however I'm using Titan's overclocking kernel, and would have to mess with recompiling and the initrd... No go for me.
If you do it, let us know here...
Well, I want to use Titan's kernel, too. Both because of the possibility overclocking and because of other kernel modules...

When I have some spare time I take another look. Thanks anyway.
 
Posts: 6 | Thanked: 17 times | Joined on Jun 2010
#28
I'm currently running my n900 with encrypted swap, /home /home/user/MyDocs.
This is possible thanks to jebbas kernel, which allows for pw input on the framegrabber console.

Unfortunately the hildon gui still randomly display some "unsupported filesystem" messages which I cannot track to any root cause and even wierder when using the camera the device tends to reboot - despite the filesystem on the encrypted /home/user/MyDocs being vfat.

Now a couple of questions:
- Any hints regarding the "unsupported filesystem" and reboot issues?
- Any experience on running jebbas kernel on PR1.2?
- Any cleanly integrated (GUI) dm-crypt layer in sight?
 

The Following User Says Thank You to wirr For This Useful Post:
Posts: 451 | Thanked: 334 times | Joined on Sep 2009
#29
Originally Posted by wirr View Post
I'm currently running my n900 with encrypted swap, /home /home/user/MyDocs.
This is possible thanks to jebbas kernel, which allows for pw input on the framegrabber console.
So does it pause during boot and ask you for the pass?

How did you set it up, just encrypt /home and that's it?

What's your /etc/fstab

Did you have to mess with anything else, I assume since root isn't encrypted you didn't have to mess with initrd...
 
Posts: 6 | Thanked: 17 times | Joined on Jun 2010
#30
Maemo uses upstart for system init which is highly parallelized. So the trick was to make some scripts in the boot process depend on my cryptsetup script /etc/event.d/crypsetup:
Code:
start on started sgx
stop on starting shutdown

console output

script
        /etc/init.d/cryptdisks start
        initctl emit CRYPT_OK
end script

normal exit 0
And, of course in /etc/event.d/xomap add:
Code:
start on CRYPT_OK
I've adapted the partition table, crypttab and fstab:
Code:
sfdisk -l

Disk /dev/mmcblk0: 977024 cylinders, 4 heads, 16 sectors/track
Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/mmcblk0p1          1  873600  873600   27955200    0  Empty
/dev/mmcblk0p2     873601  939136   65536    2097152    0  Empty
/dev/mmcblk0p3     939137  971904   32768    1048576    0  Empty
/dev/mmcblk0p4     971905  974976    3072      98304    0  Empty
Code:
cat /etc/crypttab
# <target name> <source device>         <key file>      <options>
docs            /dev/mmcblk0p1          none            luks
userdata        /dev/mmcblk0p2          none            luks
swap1           /dev/mmcblk0p3          /dev/urandom    swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
tmp1            /dev/mmcblk0p4          /dev/urandom    cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
Code:
cat /etc/fstab 
# autogenerated
rootfs / rootfs defaults,errors=remount-ro,noatime 0 0
/dev/mapper/swap1 none swap sw 0 0

/dev/mapper/userdata /home ext3 rw,noatime,errors=continue,commit=1,data=writeback 0 0

/dev/mapper/docs /home/user/MyDocs vfat noauto,nodev,noexec,nosuid,noatime,nodiratime,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0133,rodir 0 0

/dev/mapper/tmp1 /tmp ext3 defaults,noatime 0 0

It works _somehow_.
Still random reboots and this "unsupported storage format" message popping up make it annoying to use.

Does anybody have a clue in what scripts maemo checks for "supported storage formats"?

Thanks
Wirr
 

The Following 4 Users Say Thank You to wirr For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 14:31.