Will there be any anti-theft protection in Pyra?

[dimag0g]

As the price of the device we're (hopefully) going to get soon is quite high, I'd like to discuss anti thief protection. I know that development is limited in resources and time, but an effective protection is impossible without low-level support.

The basic protection as I see it is to assign a key to each unit and verify it during reflash. There could be a file, e.g. reflash.key is required to be on SD card during reflash. This file could be e-mailed to each new customer, or requested on the forum in case it's lost. Such request would require you to give the serial number of your unit, and it would be trivial to verify if that unit is declared stolen.

Is something like this (or something completely different) planned for Pyra? If not, how hard will it be to add such feature? And finally, what do you people think - is it useful or not?

 

[matzesu]

The best theft protection will be hardware based:


Make a chain on the Wrist band atachment point, or use the wrist band whyle you use the Pyra,


Put it in your poket when you ditnt use the Pyra,


There are to many peaple, who put theyre Smartphones on the table in the pup or other places, easy to steal the expensive iphone..


I put my phone everythime back in poket, and the same whit the Pandora..


If the OS on the Pyra is like the OS on Pandora, you can easely reflash the OS whit a full flash image, so you dosnt have to hack the password..


Soo take your Eyes on your Pyra, and everything should be fine..

 

[Neelix]

@dimag0g How does this help protect against theft exactly? by the time a thief discovers such a measure, they already have the unit and are not likely to return it.

-Neelix

 

[levi]

You won't need to reflash a unit to get access to it - just put in a bootable SD card (or micro SD), just as you can on the Pandora.  That sort of hackability is part of its appeal for me.  Something hardcoded in the hardware combined with something in the OS which phones home would be less of a problem, but it'd need to be documented in public somewhere, which limits its use against a hardened tech criminal (not sure how much we have to worry about those when we're talking about pickpockets mind you).

 

[Grench]

I think his implication is that the device itself would have a private encryption key and public key.  When the OS tries to install or activate the first time (or anytime it's online) the Pyra would send it's public key and it's GPS location to the central server to say, 'here I am!'.  

The central server would then have a list of non-stolen and stolen units and could deny validation/operation to a unit who's public key was on the stolen list.  The reply to say, 'ok, go ahead' could also be encrypted using the private key such that the return code could only open the one unit in question.

If the unit is on the stolen list, police could be notified of the GPS location of the stolen goods.

The same code and authorization system could then be used to lock/unlock data files on the device as well as manage rights to media (movies/songs) and unlock codes for commercial games...

Yeah, that could theoretically be done.  Would any of us want to?  Hell no.  That kind of heavy handed DRM is pretty much 180* contrary to the flow around here.

 

[dimag0g]

@Neelix Then why do iPhones have this feature? (I'm not being sarcastic here, just curious)

@Levi Technically Pyra could require a keyfile on the bootable SD as well. People who boot from NAND would still be protected, while those who want to boot from SD just put the keyfile there.

@Grench No encryption and no calls home. The device will just refuse to reflash if the key isn't found. Encryption could be added by the user if desired, as well as "call home" functionality.

 

[Neelix]

@Neelix Then why do iPhones have this feature? (I'm not being ironic here, just curious)

Never having owned an iphone I had no idea such a feature existed, let alone why it was implemented. Though I would hazard a guess that the real reason might have had nothing to do with theft protection, even if they tell people otherwise.

-Neelix

 

[Mr_Loon]

@ dimag0g : The thing is if I was a Burglar / Pickpocket and I stole your Pyra the chances of me actually knowing what it was are pretty slim. I'm not going to think 'hey that's a pyra I won't nick that because they have a cool anti theft solution.' I'll be thinking 'that looks like an expensive electronic gadget, I'll have a bit of that'.

As for the actual idea of no reflash for stolen units, then that's not exactly a major issue / punishment, I've not reflashed my Pandora in over a year, got it set up just how I want it, if it aint broke and all that.....

 

[dimag0g]

Unability to reflash is not supposed to be a major issue by itself. It is supposed to help people who care to protect their units with a password. The idea is that you can't just skip a password by reflashing.

If the stolen unit is useless without the reflash key, it may end up being sold on e-bay for a fraction of its original price. Or it could end up in the garbage. In any case, it will teach the thief that he can't get much out of stolen gadgets, which is a good thing in the long run.

 

[levi]

Something like these 'Find my phone' apps could be coded by a developer after the release of the Pyra, and installed by users willing to pay for the small amount of data for it to check with the server that its key (set by the user at install time) hasn't been revoked (it needn't even be a public/private key, just a string or number).  It could then open an ssh channel over the network, and allow us on another computer to find their location and otherwise mess with their experience (sadly, we can't automatically take a picture of them without a camera).

An inbuilt key string would make use of this app slightly easier at first, but might be harder to remember than a user set string after a device is stolen.

A boot time check of an installed secret message which can only be decrypted by the hardware string is an interesting idea though.  You could even use the wifi chip's default MAC address on the Pandora.  It can't, programatically, be a secret from anyone using the machine, as to do that would be DRM.  And the encrypted message to be installed can't be a secret, for obvious reasons, so the mechanism of the encryption should be trivially deducible.

Perhaps some mode of operation using public key crypto could be used, but right now I'm struggling to see how it would work.  If the bootloader or the init process can obtain the secret key, then so can the user.

 

[Wally]

Cloud based remote lookup or self destruct?

 

[dimag0g]

@Levi I agree that 'Find my phone' kind of apps should be coded by a developer after Pyra is released. However, such applications can only be effective if you can't bypass them by a simple reflash.

This is where hardware support is required for protection. I don't quite understand why everyone is talking about encryption and DRM, and how it's impossible to keep the key secret. It is actually quite simple: one copy of the key is on the SD card you'd use to reflash your Pyra, which you keep at home and which doesn't get stolen. The other copy is kept in write-only memory which is only accessible to the bootloader. When asked to reflash, the bootloader compares the key on the SD card with the one stored in write only memory and goes to infinite loop in case of mismatch.

If the bootloader or the init process can obtain the secret key, then so can the user.

Not if the bootloader and the memory holding the key are inside the same chip. I mean, yeah, you can send your Pyra to chipworks, pay anywhere between $1000 and $50000 and they will open the chip and recover its contents, destroying the Pyra in the process. I doubt it's an option a thief will consider.

PS. Actually, simply removing the WE pin from the bootloader flash chip may be sufficient. Soldering back a broken pin and reading/writing a chip soldered to a PCB is hard enough to make Pyra practically unsalvageable when stolen.

 

[EvilDragon]

@Levi Technically Pyra could require a keyfile on the bootable SD as well. People who boot from NAND would still be protected, while those who want to boot from SD just put the keyfile there.

No, that won't work.

You can do a low-level boot with the Pyra (same as on the Pandora), which means:

The first piece of code the CPU runs is being loaded from the SD Card.

This is also the reason the Pyra and Pandora cannot be bricked (unlike a smartphone).

Even if the bootloader is fully broken in the device, it can boot and run code from the SD Card and reflash the bootloader.

 

[rSl]

please *no* hardware drm! this is/will be an *open* device,


right?!


sadly that means


when the hardware went into other hands it's fully in


their control and should be regarded as lost/insecure.


thats the price for freedom here i guess.


so one have to physically shield the device from getting


stolen.


tip, if you go to a demonstration, only bring the cheapest


phone with you (better none) so you can dump it completely


after a police-raid.


ah, and encrypt your filesystem so others stay safe too.

 

[bzar]

Without very intrusive measures you can't really stop the thieves from using your device, but you can stop them from using your data by encryption. Additionally you can hide a startup script on your device to send GPS coordinates to your email on every bootup as soon as the device has an internet connection and allow you some remote administration capabilities in an emergency. That's pretty much the extent one can go with an actually open device. Actually, if you want to recover your device after theft, you DON'T want the device to be password protected, only your data. That way all your tracking tools are more likely to stay active

 

[Inqui]

Wow that is an great idea. Would love to get this email-gps position-feature in the boot sequence (or something like that)


Of course in an style that the NSA isn't listening

 

[dimag0g]

Well, if it's technically impossible, there's nothing to discuss. I'm not that paranoid (not even sure I want to make a call-home script).

@Inqui The whole point is that without bootloader support all the call-home scripts disappear after a reflash. I'm not a thief so I don't know how common is to just keep using a stolen gadget with old user's data on it. But if I ever buy a second-hand Pyra (or any gadget for that matter), the first thing I'll do is reflash.

PS. AFAIK, we don't have a GPS. And even if we did, GPS doesn't work well indoors, so you'd get coordinates of the bus stops where the thief is using your Pyra while waiting. Not sure what you can do with that data.

 

[bzar]

Wow that is an great idea. Would love to get this email-gps position-feature in the boot sequence (or something like that)


Of course in an style that the NSA isn't listening

Bcrypt your coordinates and you can post them to for example mailinator. The inbox is hard to connect to you and no one else can make use of the data.

Well, if it's technically impossible, there's nothing to discuss. I'm not that paranoid (not even sure I want to make a call-home script).

@Inqui The whole point is that without bootloader support all the call-home scripts disappear after a reflash. I'm not a thief so I don't know how common is to just keep using a stolen gadget with old user's data on it. But if I ever buy a second-hand Pyra (or any gadget for that matter), the first thing I'll do is reflash.

If I was a thief I'd probably first clone the data on the device on the off chance there was something valuable in there, like saved passwords or valid session keys. In a space without wireless connectivity, of course.

 

[MrConfusion]

Since I use the Pandora at work it was essential to have SDs fully encrypted and because I was OK with a somewhat nonstandard setup it was quite trivial to achieve. If there is a speed penalty then I've grown used to it and can live with it. Works like a charm. With the Pyra it might be even better - maybe OMAP5 supports HW AES which is available for some OMAP chips in the Linux kernel?

What would really be great was a Kensington-style lockport. That would allow me to leave the device unattended slightly longer (getting a cup of coffee and such) now I've just made a habit of carrying it with me and though not that intrusive to me, it puts the device at risk (horror scenario would be a colleague saying "Whooops, what was this thing next to the coffee machine, was it something important?" when I turn my back for a second).

A Kensington slot is nontrivial in a device this small (has been done in several, but either you need some metal inside the plastic layer or some darned heavy duty plastic). If simply the tension created by the lock is enough to cause minor cracks the whole setup just looks like a tasty snack - they don't even steal, they just crack it for fun and leave the mess behind.

 

[Inqui]

I don't think, that a thief or a guy who found that pyra will do a reflash first.


So its not a truly safe option, but a hint.


And also the bootsequence think will not the best solution, cause I dont want to boot it that often.


How often do you reboot your mobile ?


Only when its bugging or you go an vacation.


Maybe an script should start, when the device is powered by an external source (that would be show the home or workingplace of the thief)