00:22:45 https://signal.org/blog/earn-it/ 00:22:45 Unfortunately, Signal seems bearish on their future if the bill becomes law, it seems. 00:23:34 Not all countries governments are that "stupid", but I wonder how "independent" one can be from the US influence in the long run. 00:43:19 It is, when you choose it in room settings 00:44:20 No, they accept cc (albeit, through PayPal) 01:18:12 Good to know as a new user but.....says encryption is disabled in this room. (?) 01:19:10 Most mass-rooms do not have it enabled 01:19:16 Only secured by SSL 01:19:25 Which, on days like today, seems unfortunate 01:20:15 (The general state of things, not that this room is unencrypted) 01:22:06 There are many reasons for public rooms not being encrypted 01:22:17 https://github.com/MilkManzJourDaddy/matrix-org/wiki/E2EE-and-Public-Rooms 01:25:46 Well, end-to-end encrypted 01:27:45 brenneke[m]: This channel is a public one, accessible to all. Turning on encryption in a public room which anyone can join is like building a 100-foot high wall around your house to keep intruders out, then leaving the gate open and not turning anyone away at the door. 01:28:13 Doing so will also break any form of bridging or interoperability and most clients don't support it 01:28:45 There would be no meaningful security gain either, because anyone can join it, and it'd also mean everyone would have to bear the burden of doing the key exchanges with all ~300 users in this channel. 01:29:01 That exact quote from you is in the link xD 01:29:07 * TheJollyRoger cracks up. 01:29:11 That's funny, hahaha 01:33:07 Rrgh. Policykit is acting up again. 01:40:35 Google and Qualcomm firmware no? 01:59:10 strcat: You've criticized the Whonix docs before. Could you be more specific? I want to fix it. I've already made a post about the host OS page because that's really bad. Anything else? 02:04:55 kohntree: don't worry about EARN IT. Shit's gonna die in committee like it did the last two times. 02:04:55 Cool. You are passionate. 02:10:34 What? That's an apt description. 02:11:09 "No! You can't look! You have to walk in the wide-open door first. Then you can look." 03:45:07 Any chance to run Gcam (with all permissions disabled)? 04:47:45 Hi bseeinu[m], at this moment while some people have discovered ways that we don't officially endorse to get gcam to run and vehemently recommend against, at this moment gcam only runs because of a loophole in a security policy that GrapheneOS may close at a future date. 04:48:31 It's also likely to stop working if Google decides to stop playing ball, so I wouldn't recommend it. OpenCamera isn't quite there yet as I understand it, but it's miles ahead of the default AOSP camera app. 05:14:42 TheJollyRoger: Could I port Graphne to a s3 05:15:17 Wait what? 05:15:41 hi skyfall007[m], if you're asking me for permission, I am not the one who can or can't give it to you but the code is under MIT license. That said, I really don't know if you'd have anything to gain from trying to port GrapheneOS to a device from... ~2013? 05:18:10 TheJollyRoger: 2012 05:18:16 (assuming it's *that* s3) 05:18:20 *sigh* 05:18:34 Yeah goodness gravy. 05:41:38 Fun fact pre AOSP the Samsung S4 was directly supported by CopperheadOS 05:44:17 GuardianROM was the only attempt at a secure rom for the S3, but it failed as it was over ambitious 05:45:56 22:41 Fun fact pre AOSP the Samsung S4 was directly supported by CopperheadOS 05:45:58 22:44 GuardianROM was the only attempt at a secure rom for the S3, but it failed as it was over ambitious 05:46:00 I remember those projects :) 05:48:05 Relics from the days of yore! 05:48:52 An S3 lacks in every single area in security. There's virtually no way to secure it now. I think even if you built your own vendor image with source you would have countless critical security vulnerabilities and no support for any sort of basic security model home to Android today. If I had a gun to my head and had to make a reasonably secure OS for the S3 likely xen4android would need to be resurrected, but even 05:48:52 then that's deeply flawed running on that hardware and has way too high of ram requirements 05:50:05 The best affordable option for a secure phone new is the Nokia 1.3. It has a snapdragon 205 with 1gb ram. It's brand new and will get consistent security updates for 3 years. It has Android 10. Disable gapps and call it a day. It will be a much better phone than an S3 in 2020 05:50:47 The other option is a used phone like a screen burned Pixel or a shattered iPhone which you should be able to find under $100 if you are willing to look at the Pixel 3 or iPhone 8 05:51:06 Something I really like to do when looking at the cost of a device is think about when I'm going to need to end up replacing it. That's always been a big factor at when I look at buying a phone. 05:51:35 Yes, I look at guaranteed support and factor price per year 05:51:48 $80 for an iPhone SE, $30ish for a Nokia 3.1, $150 for a Pixel 3a 05:52:11 I have always only given up a phone since it no longer got security updates 05:52:28 Yeah. It's not worth it for me to spend $150 on a phone if I know that even nine months, it will be a pop tart and I'll have to repeat the ordeal. At that rate, I might as well just spend the money on a Pixel 3a. 05:52:47 Hell, it'd be worth less than a pop tart at that rate because at least a pop tart makes a tasty snack. 05:53:17 Right that's what is so great about Nokia phones. Super budget price and third place in security too Apple/Google 05:53:39 If you can't afford a Pixel or iPhone then there's no shame in a Nokia 05:53:50 Nice! 05:54:12 I'll have to keep that option on my table, thanks rutxonboard[m] :O 05:55:13 I read about that when I went through all of Daniel's reddit posts. Android One is very good for the average person. I recommend them to friends all the time 05:55:30 Android One without gapps is absolutely the poor man's GrapheneOS 05:55:54 Oh huh. I haven't tried Android One before - I'm a refugee from BackdoorBerry. 05:56:07 The biggest issue is their low end used to go MediaTek, but everything is now Snapdragon 05:56:14 Beautiful. 05:56:47 For most people I recommend an iPhone. If they can't afford it Nokia. If they don't like how restrictive it is I recommend Pixel 05:57:11 Nokia is usually what my friends go for 05:58:13 Samsung promises four years of security updates for Galaxy Xcover 4s Enterprise Edition and Galaxy Xcover Pro Enterprise Edition 05:58:22 It's not perfect, there has been a telemetry scandal. Though the value and security combo is off the charts. They also make the only security focused phones with good sized screens so it is good for people who can't stomach how small a Pixel 3a XL or iPhone 11 Pro Max is 05:58:58 > Samsung promises four years of security updates for Galaxy Xcover 4s Enterprise Edition and Galaxy Xcover Pro Enterprise Edition 05:58:58 Crappy support though. After some time it is quarterly updates. Cheaper devices start as quarterly 05:59:35 Yeah. I think it was three years of montly updates and the last year quarterly 05:59:52 I am pretty sure it's 2 for a flagship 06:00:01 Could be wrong 06:00:12 Mid range phones are quarterly right away 06:00:48 Samsung is not horrible, but way too many caveats to recommend. iPhones and Pixels are both very comparable phones. Even Nokia depending on what you want 06:02:38 Samsung is definitely not the worst phone maker out there. They might even pull off a 5th place. I just wouldn't recommend them since they are so much worse than the alternatives 06:03:05 OK that's it I'm adding the term "pop tart" to my lexicon. "pop tart: n. (alt. spellings: poptart, pop-tart) - slang term for a useless, insecure, or obsolete phone now only useful as an impromptu charge pack for energy, much like the eponymous pastry which provides calories, but no nutritional value." 06:03:21 That's amazing 06:03:33 Hehehe X) 06:03:48 I hate how expensive phones are now 06:04:10 Same here :(. Some of my relatives have the bigger iPhones, and spent almost more than enough money to buy new laptops on them. 06:04:15 I can't afford a secure daily driver and a device to write for 06:04:19 We need to go back to the old days 06:05:12 > Same here :(. Some of my relatives have the bigger iPhones, and spent almost more than enough money to buy new laptops on them. 06:05:12 iPhones can be incredible value, but buying them new? No thanks. I wouldn't mind a 2 year old one with a good battery for half the price. They are basically 2 years ahead on performance anyway 06:05:22 Interestingly, there are also Enterprise Editions of some Samsung flagship devices, but those are much more difficult to buy than the standard editions 06:05:31 Yeah. >_<. 06:06:19 iPhone XS still keeps up with every Android out and still has longer support 06:06:37 Why people don't either keep their iPhones longer or buy used amazes me 06:07:28 I would like to have removable battery, which is a difficult thing to ask for nowadays 06:08:38 > I would like to have removable battery, which is a difficult thing to ask for nowadays 06:08:38 Look into Rugged Android Enterprise phones. 5 years support and I think some have removable batteries 06:08:47 They are around $1000 on 3rd party sites though 06:09:15 Yeah, but those phones rarely are supported by AOSP based projects 06:09:56 I dunno man. Stick to Google, Apple, and Nokia they are just killing it lately 06:10:18 Batteries aren't that expensive 06:10:44 I usually carry around a charge pack in my backpack... best I can do at the moment. 06:10:53 *a 10,000 mAH charge pack 06:11:18 Currently i have a Pixel 1st gen with a swollen battery... that's the problem with non-removables 06:11:32 PinePhone and Librem sure suck for security, but if that's the hill you're going to die on then they are a lot better than an ancient Android 06:11:52 * TheJollyRoger pokes a hole in the battery to let the air out :D 06:12:05 (I'm joking, don't do that) 06:12:08 hehe 06:13:47 I highly recommend the iPhone SE or Pixel 3a for anyone looking for a phone right now 06:15:40 I'll second that! 06:16:59 It's a bit of a premium option, but if you can find an Orico Multicharger charge pack with the USB-C port, keeping one of those around can be a lifesaver, especially for long car trips and such. 06:18:01 Ah yeah, pixel 3a battery life is obscene on GrapheneOS though 06:18:03 With the USB-C to USB-C or the USB-A fast charging to USB-C port, you can usually have your phone from 30% back up to 90% in less time than it takes to eat lunch. 06:18:19 Aww yes :D 06:18:30 My 3a could handle 700 miles ha 06:18:50 Wow, by bus that's quite a trip! 06:20:00 Haha ouch 06:33:28 oh the 3a has better battery? 06:33:28 Are you saying it's good or bad? 06:33:30 rip 06:33:31 pixel 2 xl is dogshit battery life :( 06:33:33 comparatively 06:33:44 battery lasts me like maybe 8 hours of actual use 06:33:52 nothing heavy either 06:34:04 > > <@rutxonboard:matrix.org> Ah yeah, pixel 3a battery life is obscene on GrapheneOS though 06:34:04 > Are you saying it's good or bad? 06:34:04 2-3 days 06:34:10 Lasts me 3-4 hours of Zoom conferencing. 06:35:04 Well, that's the difference in terms of whether something's in the foreground running and the screen is on, or the phone is idle. 06:35:17 3-4 hours of streaming is actually pretty damn good all things in. 06:55:14 Jitsi usually has my phone's battery flattened in 2. 06:55:34 (With the cameras running and all) 06:56:17 So I keep a 10,000mAH juicepack with me all the time. 06:56:28 :D 07:12:34 cx2[m]: HDR is not buggy on GrapheneOS, Open Camera just has a shit tier implementation of legacy HDR 07:13:18 cx2[m]: also if you mess with the camera settings and change them from the defaults, it stops the Pixel Visual Core on the 2 / 2 XL / 3 / 3 XL from being used which loses HDR+ 07:13:37 you definitely never want legacy HDR, it's near useless 07:14:01 the only way to use HDR would be to set up your phone on a tripod and use it to take a picture of a static scene without anything moving and that includes the wind not blowing around leaves, etc. 07:14:10 legacy HDR is not very useful 07:14:34 it takes 3 pictures and naively merges them, blurring anything that moved, and without a tripod EVERYTHING is moving 07:14:49 so HDR on a phone just gives you blurry, awful looking pictures 07:14:55 that's not what HDR+ does at all 07:16:36 HDR+ sets the camera to CONTINUOUSLY capture high quality frames and then when you take a picture it selects a bunch of those (8-12 or more) and INTELLIGENTLY merges them with an algorithm tracking what moved, etc. 07:17:12 so it captures far more image data than 1 image 07:26:55 Ahoy strcat. 07:31:23 https://github.com/GrapheneOS/os_issue_tracker/issues/137#issuecomment-617597696 07:32:02 finally some progress in narrowing down the bluetooth issues - I suggested that approach before to start narrowing it down 07:32:05 glad to see someone started 07:32:12 Very good 07:32:31 my initial guess was that hardened_malloc caused it which is why I suggested starting with that 07:32:36 I can't do it because I can't reproduce the problem 07:32:58 Understandable 07:37:54 I have a funky bug where everything goes really dark after switching between apps between normal and work profile. I assume that's upstream 07:38:10 Doesn't go away for a while 07:40:27 was color accent option taken away? 07:40:39 what color accent option? 07:41:07 if you mean something in developer options, those settings aren't meant for users 07:41:26 some are there for app developers, others for OS developers, often to test things 07:41:32 The color theme 07:41:56 Like having dark and brown theme 07:42:02 It's a normal AOSP thinf 07:43:22 android 10 has color accents 07:43:37 i was able to change it from blue to white on my primary device 07:43:43 but i dont see the option anymore 07:43:56 android always had color accents in the theme 07:44:02 r4v3r23[m]: you can't depend on developer options 07:44:23 what do you mean? it was available in prev build of graphene 07:44:28 i was able to change it 07:44:33 where was the option 07:44:36 in developer options? 07:44:41 https://www.androidauthority.com/change-system-accent-color-android-10-1025163/ 07:44:50 yes, pretty sure 07:44:59 so, as I explained, those settings aren't meant for users 07:45:01 they come and go\ 07:45:14 the settings in developer options are not features for users 07:45:32 they're for app and OS developers to test things including features that are under development 07:45:42 strange 07:45:43 developer options aren't meant to be used on a production device 07:45:55 r4v3r23[m]: why strange? I mean it's in a hidden developer options menu 07:46:02 it's hidden and not available to users, that's the intent 07:46:18 removing of settings from there is not removal of a feature for users, those settings aren't for users 07:46:27 and some of them have consequences you wouldn't realize 07:46:29 guess i got lucky getting to change it then :) 07:46:58 that dev options menu is a bunch of obscure, dangerous, and largely unsupported options 07:47:01 many come and go 07:47:09 it's hidden away for a reason 07:47:24 right but we need dev options to oem unlock/usb debug soooo 07:47:36 usb debugging isn't for production devices 07:47:52 for users submitting bug reports we need to make an app 07:48:09 > right but we need dev options to oem unlock/usb debug soooo 07:48:09 You should always turn that off after you're done 07:48:21 and then turn off dev options ideally 07:48:34 ok done 07:48:36 enable it only to disable oem unlocking again and then turn it off 07:48:50 That's what I do 07:48:52 having dev options enabled doesn't really hurt anything IF you haven't changed anything in there 07:48:59 but worth noting it usually asks for your password to enable dev options 07:49:07 it doesn't ask for your password to change stuff there once it's enabled 07:49:45 How do you recover if the OS got bricked if OEM locking is on? I've never done that 07:49:48 Recover that is 07:50:56 how would the OS get bricked? 07:51:06 if it fails to boot after an update, the firmware rolls back the update 07:51:22 verified boot ensures you have a bit-for-bit identical copy of the OS as what passed testing on the same device model 07:51:40 rutxonboard[m]: hard to see how that could happen - it never has happened 07:51:46 That's a good point, I guess it is impossible good both to get corrupted 07:52:09 rutxonboard[m]: if the flash memory actually broke I don't think being able to unlock would save you 07:52:26 rutxonboard[m]: also you can wipe data in recovery even with OEM unlocking disabled 07:52:40 Right, that's a good point 07:52:43 rutxonboard[m]: disabling OEM unlocking just reduces attack surface 07:53:39 locking the bootloader to enable verified boot is extremely important, and it provides most of the physical security that's available too (verified boot is mostly about protection against remote attackers, but it provides some more physical security too) 07:54:00 Right, you would have to have something in userdata break the system (basically impossible?) And then the recovery and backups would save you 07:54:04 disabling OEM unlocking as an additional step is just a minor reduction of attack surface by disabling the ability to unlock in fastboot mode 07:54:30 rutxonboard[m]: it's quite possible for userdata to end up corrupted somehow due to bugs in a way that breaks booting but you can always just wipe that from recovery 07:54:41 recovery doesn't read any of that persistent state so it can't break like that 07:54:43 it's stateless 07:54:58 the only thing recovery reads is the recovery command 07:55:01 Right, and if it gets a bad update it just rolls back 07:55:03 and it wipes that after trying to use it 07:55:24 recovery is just part of the boot image, alternate boot mode that boots up that recovery system and doesn't use persistent state 07:55:36 My apologies I really didn't think that through very well 07:55:42 no need to apologize 07:55:46 is the seed vault back up essential like reflashing my surrent set up when restoring? 07:55:54 * is the seed vault back up essentially like reflashing my surrent set up when restoring? 07:56:01 * is the seed vault back up essentially like reflashing my current set up when restoring? 07:56:28 r4v3r23[m]: it backs up system and app data via the standard backup service infrastructure 07:56:37 it's definitely not a filesystem image 07:56:56 what would be the best option for that? 07:57:03 for the system, it has support for backup/restore of the majority of the settings, etc. 07:57:14 and by default it fully backs up app data 07:57:18 unless apps disable backups 07:57:28 r4v3r23[m]: you can't take a filesystem image of userdata and restore it, it doesn't work that way 07:57:32 userdata is encrypted 07:57:39 gotchya 07:58:01 and there isn't a way to access all of it like that 07:58:11 if you took the flash chip in your phone and put it in another phone 07:58:20 it would not be possible to decrypt any of the data/metadata 07:58:37 Thanks to the Titan chip right? 07:58:44 no not really 07:58:51 the baseline data outside profiles is encrypted with hardware-based encryption, that doesn't involve the Titan M 07:59:14 profile data is encrypted with a combination of hardware-based encryption and credential-based encryption, it uses both as inputs to derive the key encryption key 07:59:20 hows the support for the project going? i remember saying you were having difficulty securing a model to make graphene sustainable 07:59:23 is the still the case? 07:59:23 Gotcha, I thought it did the hardware encryption I should look into that more 07:59:28 the Titan M is involved in that - it makes profile-based encryption stronger 07:59:37 rutxonboard[m]: the Titan M strengthens credential-based encryption 07:59:41 via an API called Weaver 07:59:45 * is that still the case? 07:59:54 rutxonboard[m]: Weaver has 'slots', one slot per profile 08:00:14 rutxonboard[m]: slots are basically a map of auth token -> randomly generated token 08:00:16 That's an awesome design actually 08:00:27 rutxonboard[m]: so when you create a profile 08:00:32 rutxonboard[m]: and set an auth method 08:00:52 rutxonboard[m]: the OS passes an auth token derived from the auth method and a random token to the Titan M via Weaver 08:00:56 to set it up for the profile 08:01:26 now, for future unlocks, the OS needs that random token as one of the inputs for encryption key derivation and so on 08:01:38 For a guest account(with no login) the data I assume is using the basic hardware encryption? 08:01:40 and the Titan M will only provide that random token if the correct auth token is supplied 08:01:51 rutxonboard[m]: or just a profile without a lock method 08:01:53 yeah 08:02:39 rutxonboard[m]: setting a lock method uses the lock method as an ADDITIONAL input for key encryption key derivation, and also sets up Weaver and uses the random token stored on the Titan M as another input for key encryption key derivation too 08:03:00 rutxonboard[m]: the hardware-based inputs to key derivation are still used - your lock method adds security, it doesn't remove any 08:03:29 if you use a totally shit tier lock method like a password 223344 it doesn't make the encryption any weaker than it was 08:03:30 > and the Titan M will only provide that random token if the correct auth token is supplied 08:03:30 The Titan M protects from bruteforcing with enforcing rate limiting I imagine? 08:03:42 That's amazing 08:03:59 rutxonboard[m]: it has a secure internal timer protected from tampering and enforces an exponentially increases delay that quickly reaches 1 day per attempt 08:04:26 rutxonboard[m]: the key derivation is the basic defense against brute forcing, including hardware-bound key derivation designed to prevent brute forcing on a different machine 08:04:34 rutxonboard[m]: Weaver via the Titan M is in addition to this 08:04:42 other devices can implement Weaver - it's all open source 08:04:51 rutxonboard[m]: Pixel 2 doesn't have the Titan M and still has Weaver 08:05:00 it used an NXP security chip for Weaver 08:05:27 rutxonboard[m]: it requires a secure element with persistent storage + a secure internal timer and the ability to put an applet on it implementing this 08:05:41 rutxonboard[m]: there's also 'insider attack protection' 08:06:00 rutxonboard[m]: to do firmware updates of these security chips (including the one before the Titan M), the owner account must authenticate successfully 08:06:12 rutxonboard[m]: the security chips have signature verification for updates + verified boot 08:06:20 but they ALSO enforce that the owner account has authenticated 08:06:46 rutxonboard[m]: you have 2 options really: successfully authenticate or wipe the security chip (which happens when wiping data) 08:06:55 rutxonboard[m]: otherwise can't update the firmware on the chip 08:07:07 That allows for safely flashing a custom one of they open source it? Or just from a GovtOS type situation? 08:07:27 rutxonboard[m]: no it doesn't bypass signature verification 08:07:32 it's in addition to signature verification 08:07:50 the purpose is that the US government or an insider at Google cannot make evil firmware and use it to bypass the Titan M Weaver feature 08:08:11 rutxonboard[m]: 'insider attack protection' as in it protects you from the company that makes / signs the firmware 08:08:24 even if they can be pressured into making evil firmware, it can't be installed without authenticating successfully 08:08:40 rutxonboard[m]: remember when the FBI wanted apple to make evil SEP firmware? 08:08:54 Right pre Secure Enclave right? 08:08:58 they can't pressure Google to do that, Google doesn't have the power to make a firmware update that can be installed on the Titan M without the owner account authenticating 08:09:05 rutxonboard[m]: no not really 08:09:37 They were trying to compel Apple using their own interpretation of the All Writs Act to essentially force Apple to write what I would call a "Rogue Update" which would disable the "nuke" feature. 08:09:45 it's a good design and I haven't seen something like their insider attack protection feature 08:09:46 > they can't pressure Google to do that, Google doesn't have the power to make a firmware update that can be installed on the Titan M without the owner account authenticating 08:09:46 Which defeats the point 08:09:51 Then they wanted Apple to sign it using their signing keys, and push that to the phone they had confiscated. 08:09:52 IIRC the Pixel 2 had this too with the NXP chip 08:10:11 > They were trying to compel Apple using their own interpretation of the All Writs Act to essentially force Apple to write what I would call a "Rogue Update" which would disable the "nuke" feature. 08:10:11 Which is essentially forced labor 08:10:25 rutxonboard[m]: NXP security chip on Pixel 2 *just* does Weaver and IIRC still has insider attack protection via requiring auth to do firmware updates 08:11:00 > it's a good design and I haven't seen something like their insider attack protection feature 08:11:00 That's fascinating. If they open sourced Titan M would it still be required to be built and signed by Google? 08:11:15 Not that it really makes any difference 08:11:18 rutxonboard[m]: Titan M has both of these things but also expands the functionality, it adds enforcement of verified boot state, lock state, factory reset protection (not a security feature - anti-theft feature) and the StrongBox hardware keystore implementation which is by far the largest feature and includes features like physical confirmation support via the power button 08:11:33 rutxonboard[m]: open sourcing firmware doesn't mean you can install modified versions of it 08:11:45 you can build it yourself and use their signature as long as builds are reproducible 08:11:53 The firmware is digitally signed by Google and digitally validated directly by the chip, right? 08:11:57 rutxonboard[m]: it shouldn't be possible to install modified firmware on these kinds of security chips 08:12:07 TheJollyRoger: yes it verifies the signatures of updates *and* has verified boot 08:12:23 TheJollyRoger: *and* the owner must authenticate before it accepts firmware updates at all 08:12:41 Wow. Verified boot, for a device that acts as a root of trust for verified boot within the device. 08:12:42 TheJollyRoger: you can look at the source code for the Pixel 2 security chip 08:12:48 WOW! 08:12:58 > rutxonboard: it shouldn't be possible to install modified firmware on these kinds of security chips 08:12:58 That's a brilliant design. I'm not surprised Google doesn't advertise that feature 08:13:03 it's a proprietary NXP security chip but the Google code is open source 08:13:08 rutxonboard[m]: well they kinda do 08:13:11 That's awesome 08:13:16 they advertise the security chip and have blog posts about it 08:13:19 * TheJollyRoger needs to make a "Yo dawg, I heard you like verified boot so we put your verified boot in your verified boot..." 08:13:34 Sec, I'll go and dig it up. 08:13:47 https://android.googlesource.com/platform/external/libese/+/android-10.0.0_r30/apps 08:13:54 here are the security chip applets used on the Pixel 2 security chip 08:14:01 and can be used elsewhere 08:14:27 > they advertise the security chip and have blog posts about it 08:14:27 Is hands on and blog posts your main wat of learning about this stuff? I haven't really found whitepapers or anything 08:14:36 https://android.googlesource.com/platform/external/libese/+/android-10.0.0_r30/apps/boot/ was the early draft of security chip enforcement of verified boot / lock state 08:14:39 I do enjoy researching this stuff 08:14:46 wasn't actually used on the Pixel 2, it enforced it via the SoC only 08:14:53 didn't ship 08:15:03 https://android.googlesource.com/platform/external/libese/+/android-10.0.0_r30/apps/weaver/ 08:15:05 is weaver 08:15:13 on the Pixel 2 NXP chip 08:15:20 Oh, beat me to it XP. 08:15:29 Interesting, I can't wait to see what Google can do if they start making their own chips 08:15:44 I'm looking forward to hearing about OpenTitan. 08:16:14 https://android.googlesource.com/platform/external/libese/+/android-10.0.0_r30/apps/weaver/card/src/com/android/weaver/core/CoreSlots.java#195 08:16:18 is where it throttles attempts 08:16:33 rutxonboard[m]: this code is the Pixel 2 Weaver applet for the NXP security chip 08:16:39 which is basically a standard Java smartcard 08:16:57 That's awesome reading that code right now 08:16:59 where they signed the firmware, implemented insider attack protection and included this weaver applet 08:17:36 rutxonboard[m]: so, Weaver + insider attack protection were carried over to the Titan M - which is their own security chip (it is their own hardware, just not their own SoC design - it's a standard ARM secure element SoC design) 08:17:49 rutxonboard[m]: they did design and manufacture the Titan M themselves 08:18:15 Essentially there's little to gain security wise them 08:18:15 Then* 08:18:19 rutxonboard[m]: Titan M adds a production implementation of the 'boot' applet there to enforce verified boot and lock state 08:18:24 By building their own SOC 08:18:37 rutxonboard[m]: and adds factory reset protection support (i.e. it has a little data section usable by the OS to implement FRP) 08:18:51 rutxonboard[m]: which is an anti-theft feature - we don't use that 08:19:35 rutxonboard[m]: basically what they do is put a token in there that maps to your Google account so that after a factory reset it's still tied to your account and forces login after boot 08:19:41 rutxonboard[m]: anti-theft feature 08:19:51 to make it not tied to your account you have to remove your account 08:20:08 rutxonboard[m]: that makes it so someone that steals the device and wipes it via recovery can't use it even tho they wiped all the data 08:20:17 So it's like the iCloud Lock that junks iPhones? Very broadly speaking 08:20:21 Oh gotcha 08:20:31 That makes more sense 08:20:34 rutxonboard[m]: yes, it's on all Android phones, but Pixels have a secure element based implementation 08:20:44 Yeah. Incentivizes returning the phone to discourage steal-and-sell. 08:20:47 rutxonboard[m]: usually there's just a frp partition used for this little bit of data 08:21:03 rutxonboard[m]: pixels got rid of that and put it on the Titan M via a tiny little API for setting and retrieving a small block of data there 08:21:08 rutxonboard[m]: it's really super overkill 08:21:16 This is all very impressive, I didn't know how far ahead Google was 08:21:27 In hardware level security 08:21:48 Wow. So to circumvent factory reset protection, they have to attack the HSM itself... which is paranoia-level secure. Brilliant. 08:21:50 so gen 1 chip on Pixel 2 (NXP chip) had Weaver, insider attack protection 08:22:22 Titan M has Weaver, insider attack protection, verified boot enforcement, lock state enforcement, factory reset protection enforcement, and StrongBox keystore 08:22:44 the biggest feature by far is the StrongBox keystore - it's an HSM implementation of the standard keystore API used by the OS and apps 08:22:55 rutxonboard[m]: so for example, that's what Auditor is based on 08:23:03 it uses a hardware-backed key with attestation enabled 08:23:30 it generates a persistent key used to identify / verify the pairing with that device via signatures from the hardware-backed key 08:24:08 and it turns on attestation which adds attestation metadata to the public key certificate (private key cannot be exported from the keystore of course, just the public key certificate) 08:24:42 the public key certificate is signed by the batch key in the keystore which chains to the attestation root 08:24:50 Auditor pins that certificate chain rather than relying on the root cert 08:25:02 rutxonboard[m]: anyway lots of apps have a use for the keystore 08:25:18 For the other phones that support your app 08:25:20 rutxonboard[m]: as an example an SSH client can generate an RSA or ECDSA key in the keystore 08:25:21 What are they doing? 08:25:28 rutxonboard[m]: there is a traditional TEE-based keystore 08:25:37 rutxonboard[m]: and then StrongBox == secure element based keystore 08:25:43 Pixel 3 and 3a have StrongBox via Titan M 08:25:58 very new Samsung phones with a Qualcomm SoC implement StrongBox via Qualcomm SPU 08:26:14 rutxonboard[m]: the keystore API is an HSM API basically 08:26:29 the traditional one is implemented via the TEE and has a lot more features / algorithms and "unlimited" storage for keys 08:26:54 rutxonboard[m]: because the way that the TEE stores data is it encrypts it with a hardware-bound key and then passes the data back to the OS to be stored by the TrustZone service 08:27:17 rutxonboard[m]: so one of the issues with the traditional approach is that someone could save this encrypted data and try to do a replay attack 08:27:28 rutxonboard[m]: so there is an optional 'rollback resistance' feature 08:27:41 rutxonboard[m]: which uses the Replay Protected Memory Block to store data to prevent replay attacks 08:27:52 rutxonboard[m]: an example would be lets say you delete a key in the TEE-based keystore 08:28:13 so it really just ends up deleting encrypted data it stored via the OS 08:28:26 it can't really reliably get rid of it or ensure it wasn't copied elsewhere by a compromised OS 08:28:26 I'm not confident I know what HSM stands for 08:28:30 hardware secure module 08:28:33 security chip basically 08:29:00 Okay Hardware Security Module that's what I thought, wanted to be sure 08:29:42 rutxonboard[m]: using the StrongBox (HSM) keystore is as simple as doing builder.setIsStrongBoxBacked(true) 08:29:58 rutxonboard[m]: it's the same API as the traditional TEE-based keystore, with fewer supported features / algorithms 08:30:13 rutxonboard[m]: https://developer.android.com/training/articles/keystore#HardwareSecurityModule 08:31:01 and if you're curious why it supports 3DES, it's because banks and financial services heavily use it and wanted it included despite stripping away most of the algorithms 08:31:03 *shrug* 08:31:16 Heh. Well... 08:31:28 and it's a simple symmetric algorithm so it doesn't add much attack surface or complexity at all 08:31:52 It's kinda funny how 3DES soldiers on and refuses to die... *sigh* kinda crazy. 08:31:59 rutxonboard[m]: so the way the keystore works is you either generate or import a key, and the private key can never be exported 08:32:09 it tracks whether the key was generated internally or imported as one of the key properties 08:32:19 rutxonboard[m]: and then from that point on the OS can only use the key within the constraints placed on it 08:33:20