6 ms·

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,

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".
- devops99 2y ago
  A solution in production today I am aware of is new to some (and very not new to others) and relatively still somewhat novel, but it is not really bespoke anymore, this pattern specifically was standardized many years ago. I am also aware of relatively young hackers implementing these things themselves. An in-kernel binary blob, and untrustworthy binary blobs running on other "hidden cores", very similar to the Intel ME/AMT situation, is a problem that many acknowledge is very serious. Perhaps I am among few who attempted to solve this problem, and did solve this problem, but I am not at all in a minority who view it as a very serious, and intolerable problem. Anyone worth their salt does view the problem as intolerable, the difference on our side is we did something about it. > the one problem you're focused on while creating many more. What "many more" problems do you speculate have been created with this approach? This is what I was hoping you could contribute, but I don't see this in your response. I wish I could write that I am disappointed. > So far, your allusions fit the all-too-common pattern of security through obscurity. Eliminating binary blobs that run in kernel space on the compute board where the user's messages are decrypted and displayed is not "security through obscurity", this is a hard technical difference and is not obscurity. I am rather disappointed that you spent the time to respond, yet either did not read my previous post, or did not comprehend it, or just didn't consider the implications ; I believe the third is the case. As you implicitly acknowledge yourself, an ASUS KPGE with zero blobs, we CAN NOT run binary blobs in kernel space, or binary blobs in an Intel ME/AMT equivalent situation, and have a system we can -- if we are being honest with ourselves -- trust to be secure. > I believe it's the best security I'm currently able to achieve with Our "device" does not fit in the pocket, we don't at this time have the means to fit it in a pocket, so we did not attempt this. Users who value the pocket experience over an ipso facto secure device are not our audience (and we don't respect such users). What we have does have better battery life than a device intended for a pockete, better radio connectivity to cell towers, and is inherently meant to also communicate with the lowest common denominator. What our device also does, is provide a fair playing field for open source software to achieve meaningful security with others who also acted on a better value system by making a choice to do so. Yes, the network effect is small, but when the other users are your spouse, or your children, or your best friend, or the other board members of a corporation you oversee, or members of your congressional staff, or a journalist, the network effect although not quantitatively meaningful is qualitatively extremely meaningful. > If you think you're a specific target of state/corpo attackers, then current best answer is "don't trust your phone". Thank you for acknowledging the problem we solved, you arrived at the same answer we had already arrived at: do not trust the system-on-chip running binary blobs on hidden cores with a binary blob bootloader and also binary blobs in kernel. > but I believe it's the best security I'm currently able to achieve My camp, fortunately, has different capabilities. > then please by all means share! I would love to see it. I expect someone will be able to do this in a proper way this coming year. At this time I post what I can post here because I would like to see others who have the wherewithal -- which is a matter of willpower, not economic status -- do this. As of today, the general software developer / IT admin but-not-actually-a-hacker crowd has no idea how fucked it really is.

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".

devops99 2y ago
A solution in production today I am aware of is new to some (and very not new to others) and relatively still somewhat novel, but it is not really bespoke anymore, this pattern specifically was standardized many years ago. I am also aware of relatively young hackers implementing these things themselves. An in-kernel binary blob, and untrustworthy binary blobs running on other "hidden cores", very similar to the Intel ME/AMT situation, is a problem that many acknowledge is very serious. Perhaps I am among few who attempted to solve this problem, and did solve this problem, but I am not at all in a minority who view it as a very serious, and intolerable problem. Anyone worth their salt does view the problem as intolerable, the difference on our side is we did something about it. > the one problem you're focused on while creating many more. What "many more" problems do you speculate have been created with this approach? This is what I was hoping you could contribute, but I don't see this in your response. I wish I could write that I am disappointed. > So far, your allusions fit the all-too-common pattern of security through obscurity. Eliminating binary blobs that run in kernel space on the compute board where the user's messages are decrypted and displayed is not "security through obscurity", this is a hard technical difference and is not obscurity. I am rather disappointed that you spent the time to respond, yet either did not read my previous post, or did not comprehend it, or just didn't consider the implications ; I believe the third is the case. As you implicitly acknowledge yourself, an ASUS KPGE with zero blobs, we CAN NOT run binary blobs in kernel space, or binary blobs in an Intel ME/AMT equivalent situation, and have a system we can -- if we are being honest with ourselves -- trust to be secure. > I believe it's the best security I'm currently able to achieve with Our "device" does not fit in the pocket, we don't at this time have the means to fit it in a pocket, so we did not attempt this. Users who value the pocket experience over an ipso facto secure device are not our audience (and we don't respect such users). What we have does have better battery life than a device intended for a pockete, better radio connectivity to cell towers, and is inherently meant to also communicate with the lowest common denominator. What our device also does, is provide a fair playing field for open source software to achieve meaningful security with others who also acted on a better value system by making a choice to do so. Yes, the network effect is small, but when the other users are your spouse, or your children, or your best friend, or the other board members of a corporation you oversee, or members of your congressional staff, or a journalist, the network effect although not quantitatively meaningful is qualitatively extremely meaningful. > If you think you're a specific target of state/corpo attackers, then current best answer is "don't trust your phone". Thank you for acknowledging the problem we solved, you arrived at the same answer we had already arrived at: do not trust the system-on-chip running binary blobs on hidden cores with a binary blob bootloader and also binary blobs in kernel. > but I believe it's the best security I'm currently able to achieve My camp, fortunately, has different capabilities. > then please by all means share! I would love to see it. I expect someone will be able to do this in a proper way this coming year. At this time I post what I can post here because I would like to see others who have the wherewithal -- which is a matter of willpower, not economic status -- do this. As of today, the general software developer / IT admin but-not-actually-a-hacker crowd has no idea how fucked it really is.