9 ms·

If your core value/goal is security, then it is tantamount to eliminate the potential for software that is not device owner-controlled to undermine Signal's sec

If your core value/goal is security, then it is tantamount to eliminate the potential for software that is not device owner-controlled to undermine Signal's security by stealing private keys. This means 1.] no closed source OS and 2.] no closed source software somewhere else on the system-on-chip either in the form of a closed source bootloader or "baseband firmware" or other "firmware" running on "hidden cores". This disqualifies all iPhones, Pixel handhelds, and Samsung handhelds. If something else such as some kind of "user convenience" supersedes the core value/goal of security, then the below is not for you. But rich people and the economically less advantaged alike can all have this solution, one way or another. The only way to achieve the goal is to run a modified "libre" (zero binary blobs) branch of GrapheneOS on a compute board that can load and run Linux without requiring any binary blobs to do so itself. This rules out any compute board (that I am aware of) that has a 5G radio on it. We could use a 5G radio as a WWAN card, but these all require closed firmware and we don't really have a way to protect a host system from them. So, running another separate compute board that does have a 5G radio on it is necessary. Another way to achieve the goal is a system-on-chip that is 100% libre and trustworthy, but good luck with that. Maybe the Librem 5 is (honest speculation) a viable candidate. The secure boot problem is also not easy to solve. One way is a read-only SD card, but this has limitations. Another way is, and you might have guessed: another compute board. This isn't an uncommon pattern already, see F-Secure's Armory MK II device (which has a wireless chip on it that can be removed via heatgun). Since we are already running more than one compute board, we can use additional separate compute boards for encryption and decryption, if we want to. To interface with the board that runs GrapheneOS, a USB touchscreen that is smartphone-sized can be used. The culmination of all of this is a very small backpack containing the compute boards, battery, maybe antenna, etc. Very rich people and their families already have these kinds of solutions. Other people who are rich in other ways (hacker's mind and motivation) also already have these kinds of solutions.

mindslight 2y ago
You're trying to step away from the mainstream thought for some very real reasons. But you have not developed good models to guide you once you're out in the woods.
- devops99 2y ago
  The "mainstream thought" is more concerned about what Steam games they can play than real-world InfoSec. My "mainstream" is those who attend DEF CON, Blackhat, CCC, or FOSDEM, and also possess technical competency. Ask anyone worth their salt if they can and should trust binary blobs. Ask anyone worth their salt if they can and should trust retail system-on-chip that remain effectively undocumented, sans before the hardware source files hit the ODM. https://www.usenix.org/conference/osdi21/presentation/fri-keynote If you believe "just trust me bro" regarding the kernel space binary blobs shipped with GrapheneOS or elsewhere on the system-on-chip is in the category of a "good model", those of us with seeking more than "just trust me bro" tier security are not your audience. But the actual hackers in the world agree 1,000% with my mindset. > But you have not developed good models to guide you once you're out in the woods. I have GrapheneOS with zero binary blobs, and a solution based on compartmentalization that has been demonstrated to work in production even for the most user-iest of users. If you believe you have something to contribute to improve it, please do.
  - mindslight 2y ago
    I tried to keep my message brief and non-specific in hopes that you wouldn't jump on me. But alas. The type of "model" I'm talking about are threat models that create practical security for yourself, without them "proving too much" and making you fall into the trap of designing bespoke solutions that solve the one problem you're focused on while creating many more. > If you believe "just trust me bro" regarding the kernel space binary blobs shipped with GrapheneOS or elsewhere on the system-on-chip is in the category of a "good model" No - but I believe it's the best security I'm currently able to achieve with a device that fits in my pocket, has long battery life, is in frequent contact with cell towers, and is inherently meant to communicate with other people running similar devices. > I have GrapheneOS with zero binary blobs, and a solution based on compartmentalization that has been demonstrated to work in production even for the most user-iest of users. If you think you've got a better approach for secure hardware to run Android on, then please by all means share! I would love to see it. So far, your allusions fit the all-too-common pattern of security through obscurity. For perspective, my main desktop/server is an Asus KGPE with zero blobs in the main processor domain. I just don't see the point of fixating on this for the mobile ecosystem dumpster fire - over there mitigating mass surveillance is the best one can hope for. If you think you're a specific target of state/corpo attackers, then to me the current best answer is "don't trust your phone".

mindslight 2y ago

You're trying to step away from the mainstream thought for some very real reasons. But you have not developed good models to guide you once you're out in the woods.

devops99 2y ago
The "mainstream thought" is more concerned about what Steam games they can play than real-world InfoSec. My "mainstream" is those who attend DEF CON, Blackhat, CCC, or FOSDEM, and also possess technical competency. Ask anyone worth their salt if they can and should trust binary blobs. Ask anyone worth their salt if they can and should trust retail system-on-chip that remain effectively undocumented, sans before the hardware source files hit the ODM. https://www.usenix.org/conference/osdi21/presentation/fri-keynote If you believe "just trust me bro" regarding the kernel space binary blobs shipped with GrapheneOS or elsewhere on the system-on-chip is in the category of a "good model", those of us with seeking more than "just trust me bro" tier security are not your audience. But the actual hackers in the world agree 1,000% with my mindset. > But you have not developed good models to guide you once you're out in the woods. I have GrapheneOS with zero binary blobs, and a solution based on compartmentalization that has been demonstrated to work in production even for the most user-iest of users. If you believe you have something to contribute to improve it, please do.
- mindslight 2y ago
  I tried to keep my message brief and non-specific in hopes that you wouldn't jump on me. But alas. The type of "model" I'm talking about are threat models that create practical security for yourself, without them "proving too much" and making you fall into the trap of designing bespoke solutions that solve the one problem you're focused on while creating many more. > If you believe "just trust me bro" regarding the kernel space binary blobs shipped with GrapheneOS or elsewhere on the system-on-chip is in the category of a "good model" No - but I believe it's the best security I'm currently able to achieve with a device that fits in my pocket, has long battery life, is in frequent contact with cell towers, and is inherently meant to communicate with other people running similar devices. > I have GrapheneOS with zero binary blobs, and a solution based on compartmentalization that has been demonstrated to work in production even for the most user-iest of users. If you think you've got a better approach for secure hardware to run Android on, then please by all means share! I would love to see it. So far, your allusions fit the all-too-common pattern of security through obscurity. For perspective, my main desktop/server is an Asus KGPE with zero blobs in the main processor domain. I just don't see the point of fixating on this for the mobile ecosystem dumpster fire - over there mitigating mass surveillance is the best one can hope for. If you think you're a specific target of state/corpo attackers, then to me the current best answer is "don't trust your phone".