[HN Gopher] A Touch of Pwn - an investigation into fingerprint s...
       ___________________________________________________________________
        
       A Touch of Pwn - an investigation into fingerprint sensors for
       Windows Hello
        
       Author : mwexler
       Score  : 38 points
       Date   : 2023-11-22 13:56 UTC (9 hours ago)
        
 (HTM) web link (blackwinghq.com)
 (TXT) w3m dump (blackwinghq.com)
        
       | paxys wrote:
       | This is pretty much a certainty when the laptop, OS and security
       | peripherals are all made by different companies. The only real
       | security comes from tight vertical integration.
        
         | moolcool wrote:
         | I think it's more that most mainline Windows laptop vendors
         | suck at writing software and firmware. Try to spend an hour
         | with an HP or Acer laptop.
        
           | tpurves wrote:
           | Coming from being used to apple laptops, I was shocked at how
           | bad even microsoft-branded surface devices were at sw/hw
           | integration and useful quality of components in general.
        
             | moolcool wrote:
             | I had the original Surface Laptop at a previous job. If I
             | remember correctly, I had to RMA it four times for
             | different assorted catastrophic hardware failures. I lined
             | my cubicle wall with their RMA receipts.
        
         | izacus wrote:
         | As mentioned in this thread, tightly integrated apples aren't
         | all that great either.
        
           | mannykannot wrote:
           | Tight integration is necessary - (in)security does not
           | respect boundaries - but it is not sufficient. if your
           | vendors are not doing it right, it's still your problem.
        
         | gustavus wrote:
         | > The only real security comes from tight vertical integration.
         | 
         | Yep because when I think of Microsoft I think security. It's
         | not like they ever did something mind numbingly stupid like
         | decide to default to the administrative user if you called the
         | Azure API without an AuthZ header......
        
       | oneplane wrote:
       | Without cryptographic pairing (and a hard requirement at that)
       | and secure channels that aren't optional, none of the setups can
       | really be secure. SDCP tried to do this, but with so much being
       | optional and scoped smaller than the actual attack surface (pun
       | intended), it's about as good as TPM-over-LPC.
       | 
       | As soon as it's optional or can be exchanged/replaced with no
       | side-effects, you're screwed.
        
       | tpurves wrote:
       | I was a little dismayed to learn that 'supports linux' is
       | regarded as an indicator that a machine could be easier to
       | compromise :o
        
         | Hello71 wrote:
         | you could also say that "supports linux" allowed them to
         | discover and remedy this vulnerability which would likely have
         | still existed without linux support, thus making the device
         | stronger for both windows and linux users.
        
         | londons_explore wrote:
         | It's understandable though... 'supports linux' tends to mean
         | secure boot isn't enforced, and you have a much higher chance
         | of being able to just boot from a USB and dump the disk...
         | 
         | I was disappointed when I installed linux on my laptop to find
         | that a default ubuntu install could mount and decrypt a
         | bitlocker encrypted windows drive with no trouble - while I was
         | under the impression that the encryption keys were locked deep
         | in the TPM and couldn't be extracted by anything but a securely
         | booted windows installation.
        
           | masfuerte wrote:
           | This is quite sensible. By default, you don't want a hardware
           | failure to make your data irretrievable. You need to
           | explicitly opt-in.
           | 
           | https://superuser.com/questions/1299600/is-a-volume-with-
           | bit...
        
             | quietbritishjim wrote:
             | > By default, you don't want a hardware failure to make
             | your data irretrievable.
             | 
             | Er, what? Of course you do! At least if you've chosen to
             | encrypt it. That's the whole point of doing so! Using
             | Bitlocker _is_ the explicit opt-in.
        
               | masfuerte wrote:
               | When I installed Windows 10 Bitlocker was turned on from
               | the get go. I didn't choose it. Then it grumbled that it
               | was "waiting for activation", which led me to the
               | superuser post I linked to.
        
               | quietbritishjim wrote:
               | Ah ok that's different. Yes you want the computer to be
               | (effectively) unencrypted until you say so, but that
               | should be really clear too.
        
               | mewse-hn wrote:
               | Yep Microsoft has started trying to do bitlocker-by-
               | default, it sits at "waiting for activation" until the
               | user signs into windows with a microsoft account and then
               | it ties the bitlocker to the person's microsoft account.
               | 
               | Then an errant bios update can brick the computer.
               | 
               | (Please don't) ask me how I know.
        
               | Dalewyn wrote:
               | Windows 11 (and maybe Windows 10?) default to Bitlocker
               | activated if it realizes it's installed on a laptop or
               | other mobile device.
               | 
               | This means it's an opt-out situation and the user
               | probably isn't aware that a boot failure or hardware
               | failure can brick all his data that he really should keep
               | backups of.
        
               | willis936 wrote:
               | Indeed and it's always good practice to keep the key
               | backed up somewhere safe. Often times you need to
               | manually enter the bitlocker key after a hardware change.
               | This is only slightly inconvenient and exactly what
               | should happen.
               | 
               | Popular linux distros being behind Windows on this front
               | is one of the key reasons I still daily Windows.
        
           | bri3d wrote:
           | > a default ubuntu install could mount and decrypt a
           | bitlocker encrypted windows drive with no trouble
           | 
           | This means BitLocker was off or "Pending Activation," so the
           | Volume Master Key (VMK) was available in plaintext rather
           | than sealed.
           | 
           | When BitLocker is "On," the default is to seal the VMK using
           | TPM PCRs 0, 2, 4, 7, and 11, so tampering with the Firmware
           | (PCR0), UEFI Extensions (PCR2), UEFI Boot (PCR4), Secure Boot
           | State (PCR7), or the BitLocker state itself (PCR11) will
           | result in a failure to decrypt the key. Of course, there are
           | vulnerabilities at every stage (especially sniffing key
           | material as it transits the TPM), but the concept is
           | reasonably sound.
        
             | drited wrote:
             | Is this why people elsewhere in this thread are saying that
             | a bios update can brick a machine which uses bitlocker? I
             | guess if a user doesn't have the key saved, a bios update
             | would result in a request for the decryption key that can't
             | be satisfied?
        
           | mistrial9 wrote:
           | malicious and/or willfully ignorant rumor -- supports linux
           | is only _prevented_ by manipulative and secretly negotiated
           | boot locking from Redmond and friends
        
           | pdntspa wrote:
           | You can always encrypt the drive with VeraCrypt, no TPM
           | needed
        
       | amluto wrote:
       | Wait, the match-on-sensor devices don't have a token (hash of
       | fingerprint or whatever) associated with the actual enrolled
       | fingerprint that the host stores? If there was one, then a
       | fingerprint enrollment would only work if the host had the token.
       | 
       | IMO this should work a lot more like U2F: the host stores an
       | opaque blob containing the encrypted biometric data, and the
       | device would decrypt the blob and verify the fingerprint. Heck,
       | this plus a proof that the device was able to decrypt the blob
       | would defeat all three attacks.
        
       | mimi89999 wrote:
       | I wonder how safe libfprint drivers are
        
       ___________________________________________________________________
       (page generated 2023-11-22 23:01 UTC)