My paranoia phone wishlist

Librem Phones (Librem 5)
#1

For the sake of improving security and usability for everyone, I thought I would post a wishlist of the features that would most likely make me, as a paranoid individual, purchase a Librem. I realize that these individual items would be better discussed in their own threads, but I didn’t want to spam the forum. It’s fine if someone else wants to do that.

Here they are, in order from extremely high priority to merely high priority:

  • Polymorphic IMEI. It’s OK if I need to power cycle to get a new one. Two modes would be nice to choose from: (a) random (generates an IMEI which complies with standards, but is otherwise unpredictable) and (b) camoflage (generates an IMEI which mimics those most consistent with existing phones or phones sold at the last known phone location, or whatever would otherwise blend in with the environment).

  • Ability to pick up the phone as close to the point of manufacturing as possible. No shipping antics allowed. I assume by default that your manufacturing is compromised on a transistor level or perhaps even a device firmware level, but so is everyone else’s, most likely, so I don’t regard that as a (relative) negative. Ann Arbor, Baby!

  • Ability to run Signal Private Messenger, ideally, or some equivalently open-source messenger program that all my nonparanoid friends can also install on their Androids and EyePhones.

  • Fake permissions. This means that when, say, an app wants to use the camera, I get a dialog that says “Choose one of the following. You can change your choice later by going to such-and-such setup menu.” The choices are (a) allow, (b) deny, © fake. “Fake” means to fake out the device. So if this app really insists on camera access, it can get access to a fake video stream that provides it with entertaining blackness all day long. Unfortunately, it’s not good enough just to cover the camera physically, as I might be running some other app at the same time or intermittantly which I want to provide with real camera access. Fake permissions are a big selling point because it means I can install all the bad apps I want, and they can’t actually exfiltrate anything unless I’m dumb enough to allow that. It also makes your task of porting apps a lot easier, potentially, because you don’t need to worry about so many security threats.

  • Network permissions per-app (allow, deny, or fake). In fake mode, this permission means that the app can send all the packets it wants to whatever IP it wants, and it’s told that the send succeeded. And then… nothing happens. In deny mode, it gets notified that it has no network access. Again, this is on the app level, not the system level.

  • One-shot wifi option in the settings. Wifi connections are forgotton as soon as you disconnect, or the signal is lost due to distance. This prevents the very common mistake of forgetting to turn off wifi when you leave home. It also effectively disables Wifi Pinapple attacks, for instance those which look at the history of old SSIDs that you broadcast as you walk down the street, providing the attacker with a wealth of information about your travels.

  • Google Translate (as a downloadable app, not a forced install), because the world is too small and many of us need this. (Open source would be better, but I don’t think anything comes close to the quality as of yet.) We can keep it in fake permissions prison after initial installation, so it can provide its useful functionality in offline mode. Or for those who trust it, fully online.

Attractive features unrelated to security:

  • High resolution camera with option to save photos in some lossless format. Video at 4K 60 FPS, which is basically industry standard for outdoor action videography at this point.

  • Some degree of waterproofness, or at least the option to purchase a case for the same.

3 Likes
#2

Network permissions per-app (allow, deny, or fake). In fake mode, this permission means that the app can send all the packets it wants to whatever IP it wants, and it’s told that the send succeeded. And then… nothing happens. In deny mode, it gets notified that it has no network access. Again, this is on the app level, not the system level.

Maybe firejail + iptables? I mean that if you feel confident with the terminal, you probably already can solve this issue without special software.

Just a speculation.

#3

hi ! could you please elaborate on that ? what do you mean in this context and to Purism hardware ?

#4

Already kind of granted with Librem Chat which is based on the matrix protocol.

Well just an idea you might be able to use, you can create a script/a simple app that sends you a notification to remember to kill your Wi-Fi switch when the phone detects it’s not connected to a trusted by the user network.

Well it’s going to be complicated to have both a user replaceable battery AND waterproof, I really much prefer to not use my phone in very waterish areas and be able to change my battery than having to heatgun my phone for that purpose.

#5

This whole point vanify all the other… If the hardware is compromised at a transistor/firmware level, the safest option to sleep well with your paranoia issue it’s to avoid using a phone at all. In that way, you’ll be sure that no one tracks you (but watch out the cars with darkened windows on the road, and keep clear from the ATMs, banks and basically cities!)

#6

This may be illegal in some countries. Caution advised.

Provided that it doesn’t expect a response?

Better still, give control over this behaviour or disable it. As I understand it (warnings apply), broadcasting SSIDs is done in order to reduce the time that it takes to associate with an Access Point that was previously used and which comes into range (for example, your home WiFi and you arrive home). Some people may be willing to accept the slightly longer time to associate in exchange for a smaller or non-existent WiFi fingerprint.

#7

https://forum.xda-developers.com/showthread.php?t=2652022

I am aware of laws in the UK and India which make such illegal. There were also proposed laws in the US and Canada that never passed. Of course, DON’T steal phones or try to circumvent stolen phone blacklists because that would be bad!

#8

Of course it’s illegal, and guess what, they can’t even make it happen.
The modem part, which is a blackbox by Gemalto, won’t allow you to do that,
and not because of phone stealing, because of 911/FCC/law enforcement regulations.

Also, it won’t improve your privacy, it will actually make your carrier more suspicious
about you, just like a number one suspect will always be the one who used 10 burner
phones with the same SIM (subscriber number).
Read some cases in the US (if that’s where you are from) how the usage of many devices
was actually more helpful tracking moving suspects.

1 Like
#9

Citation please

Otherwise I agree with this, if your using a “different IMEI” with the same SIM card it doesn’t do any good re privacy.

#10

Always can back up my claims with citations, and happy to do so:


http://www.law.cornell.edu/uscode/text/18/1029

And now for the real standards and how it is practically implemented, unless
you are Huawei and can put a middle finger on this spec on the USB dongles,
but then you can’t be surprised to have sanctions in place:

ftp://www.3gpp.org/tsg_sa/WG3_Security/TSGS3_09/Docs/s3-99510-3GPP%20-IMEI%20Security.doc
ftp://www.3gpp.org/tsg_sa/WG3_Security/TSGS3_06_9910/docs/AP99-101_IMEI_CR_SMG10.doc

Any vendor that is part of 3GPP will not allow you to change IMEI.
This is not the same as changing your WiFi MAC to hack your neighbor.
Changing IMEIs can be a matter of national security. Imagine that a bunch of idiots, and I don’t
care right now from each country or side, would decide to disrupt an emergency call line center
now by flooding it with fake calls from fake IMEIs without a possibility to block them.
I say idiots because mostly them will abuse it for some kind of malicious activity.
Sometimes hardware and radios must have limits the (regular) user can’t control.

1 Like
#11

Without deep-diving into this, at least superficially, I think it’s possible this may be accomplished by restructuring permissions objects and changing data-types from booleans to possibly strings. For instance, for say a Camera.Permissions.ThisCoolApp = False, it could be Camera.Permissions.ThisCoolApp = “fake”, and you could have logic that states if Permissions = “Allow” return “True”; if Permissions = “Deny” return “False”; if Permissions = “Fake” return “True” NetworkSandbox.ThisCoolApp;

This would be considered pseudocode so it lacking any syntax of course, and I’m sure there are better ways to go about it, but just what I was thinking based on what you were requesting. I like the idea as it might improve the portability of the apps as you mentioned.

Also, I would think the setting for “network amnesia” or “One-shot” wifi option in Settings wouldn’t be too hard to implement, either, and would be consistent with company and target consumer values of privacy.

#12

They will never do it. By never I mean not in any foreseeable future.
Also, you don’t need those features, since the phone will run only the apps
they ported to it. Think of it as a Symbian phone from 2006.

No 3d party will make an app for this platform, so there is no risk that any
other app will even require some permissions.
Think of it as the 1st generation iPhone, if you had one.

Even then, your suggestion is theoretical. You can limit access to the camera app
on Android today, or provide it with fake black image. Since Android 8+ you can not
provide any permissions at all and the apps will still work just won’t be able to access
the camera. There is nothing particularly new here.
They can only enforce it when the platform is big enough. Well…

#13

This claim is unfounded. You have no knowledge about their’s plans.

This can be said about any system.

This comparison is not valid.

This claim is unfounded.

This claim is false.

FUD and lies in your posts. Are you still surprised that some of your posts, particularly outrageous ones, get censored?

#14

I’m not the best person to suggest implementation details, so I’m not able to comment on your idea, but as long as this is done safely, I’m fine with it. The main thing is that the user shouldn’t have to do this. It should arrive as a feature which is easy to use (if in fact it’s implemented at all, which of course it might not be).

#15

This definitely isn’t a problem unique to Purism, which is why I’m not going to dock them any points for it. It’s not as though I have specific evidence of manufacturing compromise, either. I just assume it because it’s so easy to pull off. All you need is a mole in your workforce with a sufficient motive to sabotage the assembly lines.

On an atomic level, the attacks are physically possible but still not to my knowledge exploited in the wild, so not necessarily of present concern: We could change the ratio of P-type to N-type semiconductor in certain areas of the chip, which would allow transistors to be made which look fine on inspection, but don’t respond normally to changes in the voltage applied to the drain. Other more subtle attacks are also possible but I don’t want to mention them here.

On a circuit level, minor changes to the mask could result in anomalous circuit behavior, for example due to making a wire a little fatter and modulating the Hall effect. There are detailed descriptions available online for how to alter various semiconductor mask features in order to create what amounts to logic triggers which activate only after some pattern is repeatedly encountered. It’s kind of like having a capacitor that charges a bit each time a register is loaded with a certain value, so that it eventually builds up enough voltage to flip a switch somewhere. These exploits are difficult, although not impossible, to detect by deep physical inspection.

On the register transfer level, it’s not too hard to imagine an engineer (or simply some piece of malware) actively altering files which describe chip layout on the level of register abstraction. This is akin to chaning an executable on the instruction level after it has been compiled, but before a user actually runs it. In this case, though, the exploit leaks into the mask rendering pipeline, and ultimately causes the wrong circuit to be printed. This is easier to detect, provided that it occurs in a sufficiently large proportion of the manufactured chips. Of course ease of detection is irrelevant if either no one is looking, or we’re reliant upon a third party to do so.

…and on up the stack from there.

2 Likes
#16

I have no problem with Librem Chat if it’s properly vetted, although a practical concern is the ease with which we can convince the security-oblivious majority to install it on their less secure phones so we can still chat with them.

I think reminders to kill wifi aren’t effective because it relies too much on the human factor. I’d like to see a forget-when-out-of-range-or-disabled option. Walk too far away, or enable airplane mode, and the phone forgets its SSID history. (This could be enabled in setup options. My only concern is that it be available.)

If in fact waterproofness is at odds with a modular battery, then I would also favor the battery. Hopefully this isn’t the case, but so be it if so.

#17

I get your point, but it’s not necessarily the case that hardware compromise defeats all of security on the device. While that’s true in theory, it might not matter in practice because someone has to actively exploit the hardware vulnerability in a way that matters to you in real life. In reality, such vulnerabilities are often expensive to deliver or discover, so they’re seldom exploited, except for high-value targets, because the attacker doesn’t want the vulnerability to be discovered.

#18

I figured polymorphic IMEI might violate reglations somewhere. It doesn’t have to be enabled by default. Security is never cheap or easy, unfortunately.

It’s true that some apps simply wouldn’t work with fake network access which just routes all traffic to /dev/null. Hopefully enough of them would work in order to make such a feature useful. If not, then at least per-app network disable would be handy because in some cases we could start the app having networking enabled, then after it settles down, pull the plug.

I have no problem with a switch which enables or disables automatically forgetting SSID history upon wifi disconnect.

#19

I understand that, which is why changing IMEI should probably occur at the same time as changing SIM and probably changing physical location (all while the power is off). Everyone needs to decide for themselves on where they draw the line with communications standards compliance. Fortuantely, there are still places out there in which it’s possible to do such things without getting into trouble. In theory it would be a problem if your IMEI matched someone else’s in the same cell domain, but there are plenty of wireless issues to worry about before that one, and it could be solved by choosing another IMEI.

The biggest weakness with all of this is that your traffic would quickly reveal that you’re a Librem user, which is yet another reason to buy the phone through anonymizing channels of one form or another.

#20

Perhaps you can start a thread to discuss proposed implementation details. I’m all for it!