GrapheneOS attestation compatibility guide
grapheneos.org
Guide on using remote attestation in a way that's compatible with GrapheneOS.

cross-posted from: https://slrpnk.net/post/15995282

Real unfortunate news for GrapheneOS users as Revolut has decided to ban the use of ‘non-google’ approved OSes. This is currently being posted about and updated by GrahpeneOS over at Bluesky for those who want to follow it more closely.

Edit: had to change the title, originally it said Uber too but I cannot find back to the source of ether that’s true or not…

  • kevincox@lemmy.ml
    191·
    2 days ago

    require a separate device that looks like a calculator to use online banking

    To be fair this actually provides a very high level of security? At least in my experience with AIB (in Ireland) you needed to enter the amount of the transactions and some other core details (maybe part of the recipient’s account number? can’t quite recall). Then you entered your PIN. This signed the transaction which provides very strong verification that you (via the PIN) authorize the specific transaction via a trusted device that is very unlikely to be compromised (unless you give someone physical access to it).

    It is obviously quite inconvenient. But provides a huge level of security. Unlike this Safety Net crap which is currently quite easy to bypass.

    • Aceticon@lemmy.dbzer0.comEnglish
      11·
      2 days ago

      Those little boxes are just a bit of hardware to let the smartchip on the smartcard do what’s called challenge-response authentication (in simple terms: get big long number, encode it with the key inside the smartchip, send encoded number out).

      (Note that there are variants of the process were things like the amount of a transfer is added by the user to the input “big long number”).

      That mechanism is the safest authentication method of all because the authentication key inside the smartchip in the bank card never leaves it and even the user PIN never gets provided to anything but that smartchip.

      That means it can’t be eavesdropped over the network, nor can it be captured in the user’s PC (for example by a keylogger), so even people who execute files received on their e-mails or install any random software from the Internet on their PCs are safe from having their bank account authentication data captured by an attacker.

      The far more common two-way-authentication edit: two-channel-authentication, aka two-factor-autentication (log in with a password, then get a number via SMS and enter it on the website to finalize authentication), whilst more secure that just username+password isn’t anywhere as safe as the method described above since GSM has security weaknesses and there are ways to redirected SMS messages to other devices.

      (Source: amongst other things I worked in Smart Card Issuance software some years ago).

      It’s funny that the original poster of this thread actually refuses to work with some banks because of them having the best and most secure bank access authentication in the industry, as it’s slightly inconvenient. Just another example of how, as it’s said in that domain, “users are the weakest link in IT Security”.