Any interest in a lojack-like app for Maemo? - Page 4 - maemo.org

Benson | # 31 | 2008-06-02, 21:15 | Report

Tell the user to move it off the tablet. It's a private key, to deal with the possibility of the tablet being compromised, so you really don't want a copy of it sitting in the tablet...

kernelpanic | # 32 | 2008-06-02, 21:59 | Report

Originally Posted by

That description could mean that the client would be open-source for verification, but the server would refuse to communicate with any but official binaries -- I doubt that this was your intent, but if so, I'll be happy to write a full-page rant explaining why this is bad, without resorting to RMS-style moral arguments. (Starring Ken's back-door, of course.)

Yes that is kind of what I meant and Ken Thompson's backdoor is exactly what I was thinking of when I wrote it. Allow me explain(Then if you want, you can write your rant

)-

Upon reflection, it doesn't need to be a signature though. A hash would suffice. Since scratchbox is a virtual environment, the same code, compiled with the same options, *should* produce the same executable. (This was the entire premise of the idea and I haven't tested this so feel free to yell at me if I'm wrong here and I'll shut up.) The executable can be SHA-1 hashed and hash can be stored on the server and is valid even if you compile the daemon yourself. But once the source is modified, the binary changes, the hash doesn't match and the server refuses communication. The idea was to prevent someone from adding a backdoor or changing the scope or purpose of the application and then using the 'official server' to do sneaky nasty things...

To be honest, sneaky nasty things could be done anyway. The idea of using a centralized service that can communicate with law enforcement directly is meant to defeat some of them. For example- Joe X thinks his girl is cheating, so he 'accidentally' leaves his tablet in her bedroom then has it go into 'findme' mode.

Joe X is far less likely to do that if he knows that the service will archive everything and can forward it to law enforcement directly should Jenny Y find out what a scumbag her boyfriend is. Because of what the program is capable of, the server should use SOME measures to keep from abetting a federal crime...

If you have a better idea I'm all ears. I've been using this thread as a brainstorming session. Some of the ideas put forward have blown me away! The responses I've gotten have been amazingly well thought out and very interesting. I couldn't ask for a better group of people to bounce ideas off of.

Really, everyone- Thanks!!!

cheers,
kernelpanic

Originally Posted by

Tell the user to move it off the tablet. It's a private key, to deal with the possibility of the tablet being compromised, so you really don't want a copy of it sitting in the tablet...

Agreed! I was thinking of a setup wizard that ran on install, setup the keys and walked the user through the appropriate steps.[edit] Including passphrase protecting the private key...[/edit]

Last edited by kernelpanic; 2008-06-02 at 22:03.

briand | # 33 | 2008-06-02, 22:18 | Report

IANAL, but...

If the tablet is in possession of the criminal when the unauthorized network access takes place (which, it can be shown, only took place because the criminal was in possession of the tablet as a direct result of a prior, connected criminal act), then it is the criminal (not the actual, true owner of the tablet) that would be liable for any criminal or civil penalties arising out of the unauthorized use (be it automatic or otherwise) of the (open or otherwise) wireless network with the tablet.

...in other words, even if the 'recovery script/program' does initiate what might, in some states, be considered an illegal network access attempt, the law will have been broken by the person in possession (albeit, criminally so) of the tablet at the time.

short answer: great! that's one more charge to levy against the miscreant when he is apprehended. bring it on!

kernelpanic | # 34 | 2008-06-02, 22:30 | Report

Originally Posted by briand View Post

IANAL, but...

If the tablet is in possession of the criminal when the unauthorized network access takes place (which, it can be shown, only took place because the criminal was in possession of the tablet as a direct result of a prior, connected criminal act), then it is the criminal (not the actual, true owner of the tablet) that would be liable for any criminal or civil penalties arising out of the unauthorized use (be it automatic or otherwise) of the (open or otherwise) wireless network with the tablet.

...in other words, even if the 'recovery script/program' does initiate what might, in some states, be considered an illegal network access attempt, the law will have been broken by the person in possession (albeit, criminally so) of the tablet at the time.

short answer: great! that's one more charge to levy against the miscreant when he is apprehended. bring it on!

I doubt that would hold up. Think of a bomb in a taxi. The taxi driver is driving the vehicle and does not know of the bombs existence. But the bad guy has a remote and sets the bomb off after the driver parks and exits the taxi. The person initiating the illegal action is at fault, even if you change the analogy to a car thief instead of a cabby.

PROGRESS REPORT 2-
I've been reinventing the wheel- Nokia already replaced osso-gnupg with gnupg for Diablo in CVS. I have them compiled and installed in scratchbox AND on my tablet. Plus the full version of GnuPG in diablo means NO WEIRD DEPENDENCIES!!!

The ball is rolling!

Cheers,
kernelpanic

briand | # 35 | 2008-06-02, 22:44 | Report

Originally Posted by kernelpanic

I doubt that would hold up. Think of a bomb in a taxi. The taxi driver is driving the vehicle and does not know of the bombs existence. But the bad guy has a remote and sets the bomb off after the driver parks and exits the taxi. The person initiating the illegal action is at fault, even if you change the analogy to a car thief instead of a cabby.

yes, but your analogy strays too far from the mark, IMO. What if the cabby stole your firearm, then got shot by a police officer later that evening when they were waving it around inappropriately? It's certainly not your fault that the guy stole your weapon, is it? It is probably true that, had he not stolen it, he wouldn't have been shot... but, again, it is that person's prior criminal act (connected, prior criminal act) that started the chain of events.

while I'm not a lawyer (as stated in the previous post), I would urge my lawyer to pursue this argument in court, should the situation arise -- I'm in Florida, and plan on installing and configuring your application, once it's available.

as an aside: my loaded pistols can sometimes be found "not under my direct control", but if I can demonstrate that I showed due diligence in how/where they were stored, then I cannot be liable for anything done with them if they are stolen and/or used without my direct permission or supervision.

Benson | # 36 | 2008-06-02, 22:53 | Report

OK, so long as you're not involved with the maemo tool-chain, I suppose that works. And I won't bother with the rant, since you clearly understand the issues. I still don't see a real need for it, though, because I can't come up with any scenario where an attacker gains by modifying the daemon.

WRT Joe's snooping ways, if it's open source (and I'm completely in favor of that), he can just rip the camera-snapping and non-light-flashing bits out and make it redirect to local storage, or (if he's on a week-long business trip and doesn't have an SD) upload with mail, sftp, or whatever -- he doesn't really gain anything by using a hacked daemon with the server.

Supposing you go with the hash, there are ways different binaries would be generated (e.g. 770 vs. N8x0, linked against different libraries for different OSes), so you'd need a table of trusted hashes. And I build on the tablet, so my binaries might be different. I'm not prepared to be that untrusting, if various others are compiling and matching your binary, but I just don't like the idea, especially when I (perhaps for want of imagination) can't see any bad scenario it helps avoid...

(BTW, wasn't SHA-1 broken a couple years back? Something like 2^60-something instead of 2^80 for a collision, if my memory serves well. Not sure if that result gains anything for matching an existing hash, and it's still not much of an issue if it's 2^130 for matching

, but it might not be the best choice.)

@briand: I don't think that's right, but without a good lawyer for the thief, I'd not be horribly surprised if he did get the criminal charges for it...
But... then he slams you with a civil suit. And you lose. That's my prediction, but IANAL either.

Last edited by Benson; 2008-06-02 at 22:58.

The Following User Says Thank You to Benson For This Useful Post:
kernelpanic

kernelpanic | # 37 | 2008-06-02, 23:25 | Report

Originally Posted by Benson View Post

OK, so long as you're not involved with the maemo tool-chain, I suppose that works. And I won't bother with the rant, since you clearly understand the issues. I still don't see a real need for it, though, because I can't come up with any scenario where an attacker gains by modifying the daemon.

WRT Joe's snooping ways, if it's open source (and I'm completely in favor of that), he can just rip the camera-snapping and non-light-flashing bits out and make it redirect to local storage, or (if he's on a week-long business trip and doesn't have an SD) upload with mail, sftp, or whatever -- he doesn't really gain anything by using a hacked daemon with the server.

Supposing you go with the hash, there are ways different binaries would be generated (e.g. 770 vs. N8x0, linked against different libraries for different OSes), so you'd need a table of trusted hashes. And I build on the tablet, so my binaries might be different. I'm not prepared to be that untrusting, if various others are compiling and matching your binary, but I just don't like the idea, especially when I (perhaps for want of imagination) can't see any bad scenario it helps avoid...

Point taken.

(Plus an error in the hash compare function could hinder the app from DOING IT'S JOB.) Consider it dropped.

Originally Posted by

(BTW, wasn't SHA-1 broken a couple years back? Something like 2^60-something instead of 2^80 for a collision, if my memory serves well. Not sure if that result gains anything for matching an existing hash, and it's still not much of an issue if it's 2^130 for matching

, but it might not be the best choice.)

Not broken. just bent...
Collisions have been found in most hash functions. SHA-1 is still better than SHA-0 or MD5. There's serious debate as to whether ANY hash function is collision free. The newer ones are simply, well, newer. Which means there has been less time to test them.

Honestly, this is one of the reasons I compiled GnuPG and dumped it on my tablet. I'm not a cryptographer. I'm perfectly happy leaving that kind of thing to mathematicians. I'd rather use algorithms that have been scrutinized by the best and open-source my implementation so that people smarter than me can scrutinize it also and point out my mistakes to me...

I think this kind of development model produces the most robust product.

Cheers,
kernelpanic

Benson | # 38 | 2008-06-03, 00:00 | Report

Broken in the cryptographic sense; we found some faster way of generating collisions than brute-force. Obviously, if I'm hashing several KB into a 160-bit number, a collision with any particular result will occur one in 2^160 times by blind luck. If I'm just looking for two things with the same hash (not matching a given one), I'll only need around 2^80 tries. Any method that actually gives you collisions faster than random guessing is considered "broken"; although it's not yet feasible to crack it, it's not as secure as a simple bit-count would suggest. I don't think it's an issue here, though. (And I'm no cryptographer either; I know just about enough to read blogs by people who understand the journals and try to put it in lay terms.)

And by the way, thanks for taking the initiative on this project; I think it's going to be very useful, and my hat's off to you for coming up with ideas and working on it, while the rest of us are just spouting off ideas. (It's come up a couple times before, I even half-jotted some pseudo-code for some scripts to accomplish it, but nobody really dug in seriously like you're doing.)

kernelpanic | # 39 | 2008-06-03, 00:37 | Report

Originally Posted by Benson View Post

Broken in the cryptographic sense; we found some faster way of generating collisions than brute-force. Obviously, if I'm hashing several KB into a 160-bit number, a collision with any particular result will occur one in 2^160 times by blind luck. If I'm just looking for two things with the same hash (not matching a given one), I'll only need around 2^80 tries. Any method that actually gives you collisions faster than random guessing is considered "broken"; although it's not yet feasible to crack it, it's not as secure as a simple bit-count would suggest. I don't think it's an issue here, though. (And I'm no cryptographer either; I know just about enough to read blogs by people who understand the journals and try to put it in lay terms.)

And by the way, thanks for taking the initiative on this project; I think it's going to be very useful, and my hat's off to you for coming up with ideas and working on it, while the rest of us are just spouting off ideas. (It's come up a couple times before, I even half-jotted some pseudo-code for some scripts to accomplish it, but nobody really dug in seriously like you're doing.)

You're welcome. Actually thank whomever stole Penguinbait's tablet. I was lukewarm on it until I read that thread...

Cheers,
kernelpanic

phi | # 40 | 2008-06-04, 16:22 | Report

There's a lojack on the iphone that uses the wifi/cell triangulation. all it does is twitter to an account you set up based on a cron job. Could be easily set up on the tablet.