Feature voting page

[comradekingu]

A nice feature would be to provide sha256 sums for the images. Not only does that make for more security, but it also takes some guesswork out of determining where an error occurred.

 

[DrHAX]

"very low power state" and "GPS" are somewhat contradictory.


thatgui is right in his concerns, although I wouldn't weight them as much (and I don't feel like discussing the subject a lot more...).


You could still reflash the boot loader.


Sure, you could prevent this. But that would be against the Pandora/Pyra spirit. It would be locking it down, and you can never lock it down enough to actually make it secure, someone will always figure out a way to circumvent security measures.


Same for tracking apps installed by default, something like this would need to be /very/ carefully thought about and probably it would still be either ineffective or against the spirit of openness which is so important for Pandora and Pyra.

If the only functions are sms and gps communications at certain times say every 45 minutes to an hour.. then I'm pretty sure it won't. Destroy the battery life.


Also I find it interesting that people a're saying since somebody with the skill can reflash it regardless. According to that logic since there's people out there who can expertly lockpick doors what's the point of me locking mine? I'm saying for the low level thief who would try to pawn it off as a DS or sell it to gamestop. If a high level tech gyro hacker steals it that's a statistical outlier. Anybody could overcome any security measure with enough knowledge and skill, most people will have never heard of a Pandora, LET alone a Pyra. So your common garden variety thief won't know either, and won't have a clue to how to flash it.

 

[WizardStan]

Also I find it interesting that people a're saying since somebody with the skill can reflash it regardless. According to that logic since there's people out there who can expertly lockpick doors what's the point of me locking mine?

You are misunderstanding. There's no good analogy between the Pandora and a door lock. The Pandora is intentionally designed so that it can't be permanently locked. If we were to try and use the analogy, it's like the Pandora is a door that was specifically designed so that you could always open the door by pushing the doorbell three times, even if your key is broken: there's no lock picking required, easy access is built right into the system. No one is saying there's no point in trying to do anything, they're arguing that it may actually be impossible to do anything. Maybe tape a piece of paper over the doorbell that says "out of order" and hope someone falls for it, or doesn't know enough about the system to think of pushing the doorbell. This is by design, it is supposed to be easy to reflash, but in making it easy for the user you make it easy for a thief too.My idea is that you actually can put a better lock on the door, it may be possible to have some special command which disables the "doorbell" completely thus preventing someone from gaining access if they know the system. There's still a way into your house, you can go through the sewer, crawl through a small hole, and leverage open a heavy trap door in your basement and anyone who knows about this can always get into your house through this secret tunnel, but the casual thief won't have the key and the more sophisticated thief won't be able to hit the doorbell to bypass the lock, so only the truly devoted thief will be able to break in by means of the tunnel. And in the event that some jerk comes along and breaks your key AND issues a command to your doorbell to disable the lock, you can either crawl through the cramped sewer tunnel yourself or pay someone else to fix it.

 

[Granitehead]

Exactly. You would need to start implementing security features in the bootloader. That sounds so much like certain closed consoles (like, say, that fucking PS3-shaped brick lying on my desk) that I instinctively dislike it.

On the other hand, maybe if done properly it could be a nice feature.

"The Pyra bootrom could do similar: if it receives the special password encrypted SMS". Hmm. How does the bootrom receive an SMS? If my understanding of how stuff works is correct then the bootloader is only active during boot and can thus only receive SMS during a short period of time during start up, and only if it initializes cellular networking etc during this time, which it normally doesn't.

So the OS would need to do it. So the OS would need the ability to "brick" the Pyra directly or at least to forward the SMS to the bootloader so the bootloader can do it on next boot. Sounds complicated.

Instead of bricking it so you need a JTAG I would prefer just password-locking it (so you can still unlock it with JTAG, I guess).

Actually a password-check coming from the bootloader would be a nice and hopefully not too difficult to implement feature in general: Password is set (or disabled) on first boot. You could configure it to ask you for the password only on certain actions: To boot from external media or reflash the firmware or always. If you enter it wrong once then you cannot boot at all until you enter it correctly.

This would make a stolen Pyra with enabled bootloader password practically worthless for thieves. I would like this feature.

 

[rygD]

My idea is that you actually can put a better lock on the door, it may be possible to have some special command which disables the "doorbell" completely thus preventing someone from gaining access if they know the system.

This is interesting, since I have actually removed my doorbell.  It doesn't really pertain to the discussion, but it reminded me of that.

Actually a password-check coming from the bootloader would be a nice and hopefully not too difficult to implement feature in general: Password is set (or disabled) on first boot. You could configure it to ask you for the password only on certain actions: To boot from external media or reflash the firmware or always. If you enter it wrong once then you cannot boot at all until you enter it correctly.

This would make a stolen Pyra with enabled bootloader password practically worthless for thieves. I would like this feature.

The problem with this is that we are all fallible.  If you forget your password, what can you do to recover your Pyra?  Is this when you would resort to WizardStan's suggestion, or do you want that possibility thrown out completely?  The password issue is the same for the ideas for pseudo-bricking and otherwise disabling the device, or anything along those lines.  If you set a good password and don't use it for 2 or 3 years, then you suddenly need it will you still remember it?  I personally can't remember passwords I set for things 6 months ago and haven't used since then (but this can happen when you use unique, long passwords of mixed characters that you do not write down or otherwise record outside of your brain and the system it is used with).  Even if it is required on every boot, which will quickly become irritating if you reboot frequently, such as because your battery dying over the course of the day, if you set it aside for a little while, then return to it, either to resume using it or to sell it, if you have forgotten that password you might not be happy.  I don't mind being inconvenienced for security reasons at times (if I agree to it...I could go on for days about how the security theater that seems so popular now, and the privacy violations that are accepted by most as a part of everyday life, are not going to be produce good results, and that they don't fall into the category of "acceptable"), but I would prefer no chance of losing my Pyra because someone thought something would be funny, I have forgotten something, or it otherwise has a built in "feature" that kills it completely.

I like some of the ideas mentioned in this thread, but most seem to have some flaws.  There may be some value in something that makes the Pyra useless to a thief, but it needs to be something with a high level of success, not something that relies on an SMS message (since there is the possibility 3G, or whatever else, will be turned off when you most need it), or only comes into play when reflashing or otherwise doing things a thief is not likely to bother with.  Also, it needs to be something that can be reversed easily and with low/no cost for the actual owner, especially in the case of preventing booting.  If things continue how they are with the Pandora, I don't see the Pyra being a major target for thieves.  Wouldn't a password and encryption be sufficient?

Although he got lucky, and this solution is worse than any I have heard here (and he even says he made poor choices), it seems the best option for recovery is along the lines of how Zoz had things on his computer that he discussed in his DEFCON 18 presentation.  As for private information, either don't use your Pyra for such things, limit the damage to only this stuff (so wrong password kills the OS and everything else on SD, etc., yet leaves the bootloader functional), or don't let someone steal your Pyra...or encrypt stuff you don't want others to be able to access.  The risk and cost to me for anything more is not acceptable because of what others fear, and their refusal to take responsibility for their choices, or they would rather the thief end up with something bricked because "if I can't have it, no one can".

 

[Granitehead]

The problem with this is that we are all fallible.  If you forget your password, what can you do to recover your Pyra?  Is this when you would resort to WizardStan's suggestion, or do you want that possibility thrown out completely?  The password issue is the same for the ideas for pseudo-bricking and otherwise disabling the device, or anything along those lines.  If you set a good password and don't use it for 2 or 3 years, then you suddenly need it will you still remember it?  I personally can't remember passwords I set for things 6 months ago and haven't used since then (but this can happen when you use unique, long passwords of mixed characters that you do not write down or otherwise record outside of your brain and the system it is used with).  Even if it is required on every boot, which will quickly become irritating if you reboot frequently, such as because your battery dying over the course of the day, if you set it aside for a little while, then return to it, either to resume using it or to sell it, if you have forgotten that password you might not be happy.

I personally don't know a lot about JTAG, I just knew before something like this existed and I'm sure I saw a connector on some of the Pyra PCB pictures.If it works like I think it does and like I understand WizardStan, then it's absolutely impossible to brick an open device which has this kind of connector. You can only physically destroy it, there is no way to lock it down completely or brick it completely with just software.

So, yes, what I mean in my suggestion is to have the password check so early in the boot process that you can only get around it by reflashing the boot loader using JTAG.

And when I said "Password is set (or disabled) on first boot." then I meant it like this: On first boot it says something like "If you want you can set up a boot password. By doing this you can make it very difficult for someone who doesn't know the password to unlock your Pyra. Only set up this password if you are sure to remember it; if you forget it you might have to send in your Pyra to ED for unlocking."

So with a huge warning to only use this feature if you want it and will remember the password.

An additional feature which would also be nice is if this bootloader would also support booting from encrypted media: It would store the pass phrase for the encrypted boot media somewhere in it's storage, and this pass phrase would in turn be encrypted with the boot loader password.

That way, even with JTAG access, you couldn't get at the data, you would be essentially wiping the device while unlocking.

Keep in mind I'm no security expert. What I describe should work in theory, but for it to make sense it would need to be implemented by someone who knows what he's doing.

 

[Ligachamp]

The problem with this is that we are all fallible.  If you forget your password, what can you do to recover your Pyra?  Is this when you would resort to WizardStan's suggestion, or do you want that possibility thrown out completely?  The password issue is the same for the ideas for pseudo-bricking and otherwise disabling the device, or anything along those lines.  If you set a good password and don't use it for 2 or 3 years, then you suddenly need it will you still remember it?  I personally can't remember passwords I set for things 6 months ago and haven't used since then (but this can happen when you use unique, long passwords of mixed characters that you do not write down or otherwise record outside of your brain and the system it is used with).  Even if it is required on every boot, which will quickly become irritating if you reboot frequently, such as because your battery dying over the course of the day, if you set it aside for a little while, then return to it, either to resume using it or to sell it, if you have forgotten that password you might not be happy.

I personally don't know a lot about JTAG, I just knew before something like this existed and I'm sure I saw a connector on some of the Pyra PCB pictures.
If it works like I think it does and like I understand WizardStan, then it's absolutely impossible to brick an open device which has this kind of connector. You can only physically destroy it, there is no way to lock it down completely or brick it completely with just software.


So, yes, what I mean in my suggestion is to have the password check so early in the boot process that you can only get around it by reflashing the boot loader using JTAG.


And when I said "Password is set (or disabled) on first boot." then I meant it like this: On first boot it says something like "If you want you can set up a boot password. By doing this you can make it very difficult for someone who doesn't know the password to unlock your Pyra. Only set up this password if you are sure to remember it; if you forget it you might have to send in your Pyra to ED for unlocking."


So with a huge warning to only use this feature if you want it and will remember the password.


An additional feature which would also be nice is if this bootloader would also support booting from encrypted media: It would store the pass phrase for the encrypted boot media somewhere in it's storage, and this pass phrase would in turn be encrypted with the boot loader password.


That way, even with JTAG access, you couldn't get at the data, you would be essentially wiping the device while unlocking.


Keep in mind I'm no security expert. What I describe should work in theory, but for it to make sense it would need to be implemented by someone who knows what he's doing.

I have this opinion too. A long warning message and good information should be enough to make the user think well about it. In addition, the possibility to boot from encryptet media would be very intresting! A system as mentioned by you would be nearly impossible to "break". Also there wouldn't be the need to rewrite the whole software needed to do so. AFAIK you are already able to do such things with Truecrypt, which is an open source encryption software. I know, they dropped support and developement and marked the latest build as "unsafe" (for a reason nobody knows, maybe the NSA disliked it? ^^), but since the code is open, somebody could check it, if that hasn't already been done by their community...

 

[Granitehead]

I wouldn't use Truecrypt, there are better solutions, open source ones too.

I don't think it would be a huge lot of code to write, yes, it would be possible to mostly just hack together existing software.

But for something like this you can't just hack, you need an expert to do that properly or all the nice security features just give you a false sense of security and nothing else.

 

[WizardStan]

So, yes, what I mean in my suggestion is to have the password check so early in the boot process that you can only get around it by reflashing the boot loader using JTAG

The only problem, something I hadn't considered, is bootrom is tiny tiny tiny. It's job is to check some input pins and figure out what to load from next, copy some code into the on-chip RAM (which is also quite small), and pass off. There may not be enough room for minimal display drivers.

 

[Silent-Hunter]

Then the password entry screen could be plain text maybe?

 

[Granitehead]

Then the password entry screen could be plain text maybe?

I'm sure that's exactly what he meant with "minimal display driver".

That's exactly the kind of problem I haven't got a clue about. I can only hope someone else makes something like this.

I thought uboot lived on there, and uboot after all is able to display a menu. So where does uboot live? Can we make uboot tamper-resistant via checks in the bootrom and add the feature there?

But this would mean that either uboot would need to be signed with a private key and the bootrom would need to be able to check that signature, or if you go with simple hashes you would need to update the boot rom too every time you make a change to uboot.

With signatures you would need to modify the boot rom too when you first want your own custom uboot, to add your own private key to the allowed ones so you can sign your own uboot.

 

[WizardStan]

I thought uboot lived on there, and uboot after all is able to display a menu. So where does uboot live? Can we make uboot tamper-resistant via checks in the bootrom and add the feature there?

uboot lives in NAND, or on SD card.Boot process on the OMAP follows three stages: first it loads from a very very tiny internal ROM called bootrom. This bootrom is responsible for setting some very basic settings like a safe clock speed and pin muxing. It then checks some flags and the values of input pins to decide where to load the next stage from: typically external NAND flash, SD card, or UART; in any event, it figures out where to get the next boot stage (called xloader) and copies the code into the OMAPs internal (also very tiny) RAM. The x-loader is a little more intelligent than the bootrom: when the bootrom loads from SD card or NAND the data MUST exist at a specific location because it doesn't have enough space to handle a file system, but the x-loader residing in memory has a little bit more room for code and so can support filesystems, thus x-loader can load uboot from anywhere on the SD card or NAND flash.

I'm not going to get into the issues of attempting to lock down the device with signatures.

 

[Granitehead]

I'm not going to get into the issues of attempting to lock down the device with signatures.

Oh there are lots of problems I'm aware of and probably a bunch more.For starters, it would be difficult to implement securely and possibly annoying for the user depending on what you do and how it's implemented.