Notices

As long as the password to mount TrueCrypt partitions is also stored on the phone, there is no security. Same applies when there is a mechanism to mount those partitions just by a click on a desktop button. In these scenarios only the built-in device lock provides security. But it provides same security to ordinary, not cyphered file system as well. OK, with the exception that the later ones can be examined using hardware technique - but that's not the point.

Those users mounting TrueCrypt partitions only after interactively entering the TrueCrypt password don't need device lock on boot. What they need is a mechanism to unmount the partition after a while the user is inactive (what device lock on activity timeout would provide [edit: not exactly but in effect], would device lock be used).

Its appropriate and convenient to use the build-in device lock in conjunction with TrueCrypt if the device lock password opens everything.

On the other hand, its inappropriate to use the build-in device lock in conjunction with SMSCON because it disables SMSCON on boot.

One possibility to make TrueCrypt and SMSCON match in this issue leads to what I've said in earlier post: We need a different kind, look and feel of "device lock".

Its nothing that SMSCON should provide by itself, that's right.

If SMSCON would use the same password for unlocking the device and mounting a Truecrypt volume, SMSCON just needs to save the strong-collision-resistant hash of the password to check if the password is matched and then use that same password to mount TrueCrypt. Then clear text password is never saved on the phone.

Just if SMSCON is going to have its own locking mechanism, and user wants also to use TrueCrypt, it would be convenient to have the same password to unlock and mount the Truecrypted device and in the same time after phone has booted.

Ofcourse, if there is a desktop button to mount TC volume, it also has to open a dialog for asking the password.

Also as the device lock code can be cracked (it uses weak encryption as we know), one should not use that security code as a TrueCrypt password. But in SMSCON strong collision resistant hash algorithm, (for example sha512sum which is already ported to N900) can be used instead to store the verification code to check if TrueCrypt password is OK and unlock the device.

But yes, own "smscon"-style of locking policy would be good. One way is to put some of those critical files to that TrueCrypt volume, so for example some library which is needed by some restricted program, is really in TrueCrypted volume and in the /usr/lib there is only a soft link to the actual file. This would of course break when the said restricted program is upgraded to the newer version with apt-get, but there could be some "re-restrict" button in the SMScon-editor to fix it (or even if going to be really professional, some tricker in apt-get which would automatically fix things after upgrade).

For example to restrict calendar working in the smscon locked mode, put libcalendar_backend.so.0 from /usr/lib/ to /home/user/truecrypted/lib

edited alot the above message few times, so .... (nothing here)

zimob, encrypting whole /home/user is extremely bad idea. You do *not* want to be in need to FIASCO reflash, after doing so.

Proper way is to have dedicated partition encrypted via truecrypt, files moved there, and symlinked.

yablacky, You described it correctly - the one and only benefit of device lock code re truecrypt, is that it makes device unusable, until at least 1 reboot (either, if lock code on boot isn't asked - device locked manually - or, to reflash, wchich, obviously, require reboot). Rebooting make already mounted TC partitions unmounted, so no access to them without password and/or keyfiles.
---

Ideal solution, would be to, indeed, have some kind of "lock code" replacement, that, upon failing, result in unconditional unmounting of all TC partitions. This can be tricky, as files on mounted Tc partitions are - typically - in use (by messaging, contacts, etc), and I've observed - many times - that even forcing unmount doesn't work. a workaround, would be to reboot unconditionally upon fail to "unlock", but it would be very irritating - in case of accidental mistakes.

Of course, there is also dilemma, how to *not* "scare" thief - yablacky perfectly described it, we need solution, that make phone pretend to be in usable state.

It require some thinking, as - for example - messages, contacts, etc, stored on truecrypt partition and symlinked, behave in weird way, when don't have access to TC partition - basically, it "seems" to work, but don't save changes, etc. Such oddities could make thief/ new "owner" to reflash anyway, getting rid of SMSCON in the process.
---

i'm sure it's achievable, but would require smart programmer (yablacky, i'm looking at You ) coming with ideas to overcome problems mentioned above, and, of course, implementing those ideas.

/Estel

// Edit

for example, problem with usual things like messaging, contacts, etc, being symlinked to truecrypt part, yet, not having access to it (when new "owner" uses device) - it would require quite complicated logic, to re-create symlinks pointing to "disposable" (i.e, worthless for true owner) location, that got deleted (and truecrypt symlinks recreated), as soon as proper encrypted partition is accessible again.

It sounds PITA, but, in reality, would require few relatively simple (yet, well-tested) sh scripts. Or anyone have better idea?

I do no use TrueCrypt partitions yet, may be I should to get some experience

Its just an idea, but instead of changing or rebuilding symlinks, it could be possible to use the effect, that mounting a file system hides, while mounted, the content that was present at&below the mount point. Means: the mount point, while nothing mounted, could provide empty or fake data. Of course open files in either location could rise problems while mounting or dismounting "true" data. Its just an idea.

How nice. I lost my N900 yesterday in a night club.

Few questions.
"'Call' will issue an outgoing call to you."
Does this call to the number which sent the "Call" command, or to the master number?

And what happens when there is several Smscon commands coming at once in several SMSs when if the phone is turned on. Will Smscon do them all orderly, for example two "Call" commands from 2 different phone numbers?

I had setting "lock always" on. Now I am thinking what to do.
Already sent "Camera" and "Trackon" commands, but no delivery message yet received. I know the device had empty battery when I lost it.

Now I regret, I didn't configure remote purge script. I could easily send "Unlock"if I could first "rm -fr /home/user/MyDocs/*" somehow.

Anyway, if you are going to build Smscon own locking mechanism, please implement it so the TrueCrypt mounting could be done later then with the same password. So use fairly strong encryption (like sha512 hash).

And yes, hiding critical files under some unmounted volume (even without TC) would work OK also. In fact, it may slow the device down if software libraries are behind TC, so it may make sense to keep those restricted files in non-TC volume even if TC-support is added to Smscon. Or user can choose how secured restrictions he wants to use.

Sure. I meant something like /home/user/.truecrypted.d as a mount point to VC-ext2-volume somewhere in /home/user/MyDocs or if user wants, in SD-card somewhere. The TC-volume path should be configurable.

I hope you get it back !!

It calls the number the command comes from. It command comes from remote command server (CHECKHOST) it calls the master number.

Most of commands will be worked of stack-like whereby an new incoming command interrupts the current one and later comes back to it.

At least two COM_CALL seem to work simultaneously. But ensure not to call the same number twice! Because the receiving phone is busy with the 1st call, the 2nd call may go the mail box. Then you have a serious problem to cancel the 2nd call. There is no such SMSCON command (nice to have: could cancel finders/thiefs calls)

If you didn't get any SMSCON notifications it may not have received your commands. On the phone you're sending the commands from, you could enable sms delivery notifications.
If battery was low its probably empty now. Instead of COM_TRACKON I recommend a COM_LOCATION command. Tracking must be turned of explicitly, and it is a battery hog.

Good luck!

Lately GPS locking on that N900 has been extremely slow, I do not know the reason, so I thought Trackon would eventually send the accurate enough coordinates, where Location would fail and send coordinates centre of country.

Yes I have sms delivery notifications on, but no delivery yet.

//edit

One thing which came to my mind, whether one has locking set on or off, the initial blue "NOKIA" pic and the handshaking animation could be replaceable in SmsCon-Editor. It would help if when booting the device the screen would show a pic which would read something like: "Please return this device if lost. $20 reward. Send email to XXXXX@XXXXXX". Or do you guys think it is out of scope of SMSCon-editor? Anyone can hack it oneself also if finds the instructions, but it would be more user freindly in SMSCon-Editor.

Also, maybe out of scope, but these features (NFC,BT,WLAN,GSM cell proximity alarm) could be in Smscon.