Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New vuln in Apple M-series allowing secret keys extraction can't be patched

twitter.com

Post reply on HN
Print view View original

101–110 of 145 posts

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#101

Post by planb »

Unfortunately, I don't think the real world applications of this exploit are explained anywhere. From skimming the paper , it looks like the attacker needs to be able to a) run code on the victim's machine and b) trigger the encryption process ("For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform private key operations.")

So for a) it might be sufficient to run javascript and for b) of course there are ways to inject data into server processes, processing data submitted by clients is what servers are for.

But a happens on clients (web browsers) and b would be a way to extract encryption keys from servers. But in what case can an attacker run code on a machine where they can also trigger the encryption (constantly for an hour like in the demonstration)? The only thing that comes to my mind would be a server side code-execution-sandbox that runs SSL termination on the same machine.

edit: Maybe stealing client certificate keys?

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#102

Post by acdha »

legutierr wrote: post #45
bhawks wrote: post #21

Earlier quoted context omitted.

For cryptographic applications yes. That is why people have spent significant effort to implement constant time algorithms to replace standard math and bitwise operations. At the hardware level any optimizations that change performance characteristics locally (how long the crypto operation directly takes) or non locally (in this case the secrets leak via observation of cache timings in the attacker's untrusted code)…

> Where possible try utilizing HSMs, yubikeys, secure enclaves - any specialized hardware that has been hardened to protect key material. Are there any circumstances where this hardware is accessible in the browser? As I understand, it is not generally available (if at all) for any cryptography you might want to do in the browser.

The browser doesn’t have direct access for JavaScript but can use those for supported features. This already happens for FIDO/WebAuth using a hardware root such as a Yubikey or Secure Enclave, and I believe SubtleCrypto uses hardware acceleration in some cases but I don’t remember if it makes it easy to know that.

One thing to remember here, though, is that there isn’t anything special about key material in this attack other than it being a high-value target. If we move all crypto to purpose-made hardware, someone could just start trying to target the messages to/from the crypto system.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#103

Post by jval43 »

tsimionescu wrote: post #38
mort96 wrote: post #35

Earlier quoted context omitted.

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.

"Remote Timing Attacks Are Practical" (2003):

https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

That's on the local network. I remember a paper doing this over the internet, but couldn't find it. A similar one over the internet:

https://www.usenix.org/conference/usenixsecurity20/presentat...

But in practice it's going to be malicious JS running in your browser: https://www.schneier.com/blog/archives/2021/03/exploiting-sp...

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#104

Post by haswell »

pjc50 wrote: post #50
bhawks wrote: post #21

Earlier quoted context omitted.

For cryptographic applications yes. That is why people have spent significant effort to implement constant time algorithms to replace standard math and bitwise operations. At the hardware level any optimizations that change performance characteristics locally (how long the crypto operation directly takes) or non locally (in this case the secrets leak via observation of cache timings in the attacker's untrusted code)…

It's infuriating that all modern computers have a secure crypto TPM, but you're explicitly not allowed to use it for your own important keys, it's only for securing things against you like the DRM in certain drivers.

“Only for DRM” isn’t accurate.

I’ve been using the TPM 2.0 chip on my ASUS based Linux box to store various keys. Tooling for this on the Linux side has improved significantly [0] and it’s been supported since kernel 3.20 (2015) [1].

How effective this is at improving one’s security posture is another question and it’s probably not a huge security upgrade, but it does mitigate some classes of attack.

I’m curious why you’re saying it’s explicitly not allowed? At least for standard TPM 1.2/2.0 chips, that isn’t the case.

- [0] https://wiki.archlinux.org/title/Trusted_Platform_Module

- [1] https://www.phoronix.com/news/Linux-3.20-TPM-2.0-Security

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#105

Post by threeseed »

dalke wrote: post #87
aargh_aargh wrote: post #5

Earlier quoted context omitted.

Can you elaborate what you mean? I may be misunderstanding what you intended but how do you use traditional means of payment (credit card) without an identity? How do you check your email without identity?

What I said was that centralization is the problem. Different tasks require different levels of identification. Cash (a traditional means of payment) requires no identification. I only carry up to about $200 in cash on me, which an amount I'm willing to bear if my wallet is stolen. When I use chip&pin ("what you have and what you know") for small payments, I rarely need any authentication, and when I do it's the PIN.…

The majority of ecommerce purchases made today are done on mobile.

And majority of these would be secured via on device biometrics.

The fact that this is all happening with approval of credit card companies, banks, regulators etc means that the idea that centralisation is fundamentally flawed is simply wrong.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#107

Post by acdha »

okokwhatever wrote: post #46

As usual nobody cares about the "Average users". This is a flaw, this is a very high risk issue for everyone and should be threaded as a big problem by Apple but as the "average user" is not important anymore...

The average user is compromised by social engineering, password reuse, or not installing updates. If you’re trying to improve matters for them, put your energy into getting them to adopt passkeys and patching promptly, and asking regulators for stricter penalties for phone number spoofing and delivering spam calls. I would wager that there are more people compromised every minute that way than will ever be compromised by this bug.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#108

Post by acdha »

switch007 wrote: post #23
Kluggy wrote: post #16

Earlier quoted context omitted.

It’s a total non issue for the majority of folks. It requires local access and takes hours under very specific conditions that don’t apply to most people. How often do you run a server that will run arbitrary crypto operations on attacker controlled inputs? Plus all the secrets in the Secure Enclave are immune to this attack, so your FileVault keys and your Apple Pay cards and all that jazz are completely safe. It su…

> It’s a total non issue for the majority of folks People said the _exact_ same thing about Spectre/Meltdown. Then the JS PoCs came out

Yes, and now browsers have mitigations which make timing attacks harder. This bug also has a key dependency on being able to trigger a crypto operation in a local process, which isn’t easy to do from a browser sandbox or in general on a Mac.

The angle I’d worry about is something like a password manager, but most of those already have an authentication step and I’d be surprised if they didn’t have rate-limiting.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#109

Post by acdha »

dalke wrote: post #87
aargh_aargh wrote: post #5

Earlier quoted context omitted.

Can you elaborate what you mean? I may be misunderstanding what you intended but how do you use traditional means of payment (credit card) without an identity? How do you check your email without identity?

What I said was that centralization is the problem. Different tasks require different levels of identification. Cash (a traditional means of payment) requires no identification. I only carry up to about $200 in cash on me, which an amount I'm willing to bear if my wallet is stolen. When I use chip&pin ("what you have and what you know") for small payments, I rarely need any authentication, and when I do it's the PIN.…

> The system - whose security I trust much more than a phone's - uses a small device with a camera. The login screen shows me a pattern with colored dots. The camera reads those dots, decodes the message (and probably also validates it cryptographically) and displays a message asking me to verify I want to log in.

> I enter the PIN, and it generates a response code, which I enter.

How do they protect against phishing? That sounds like the weak MFA where attacks spoof the login page but make their own connection to your bank and pass through the challenge and response, which means that a user who doesn’t fastidiously check the hostname can be convinced to enter a TOTP, SMS, etc. code.

Phone-based WebAuthn systems are immune to that because they incorporate the hostname into the signing process so even if they convince you that they’re hugebnk.com there’s no way for you to override that and give it a response which works for hugebank.com.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#110

Post by dalke »

threeseed wrote: post #73
madsbuch wrote: post #9

Earlier quoted context omitted.

Using multiple devices: Credit cards for payment, instead og apple pay. A camera for taking pictures, instead of a camera app, a notebook to write notes, instead of an app. From my perspective the original comment is not rocket science?

What an awful and counterproductive experience. If you require someone to enter their credit card number every time they make a purchase they end up doing dumb, insecure things like storing it as a text file on their desktop. And having external hardware just means more cables, batteries, updates to keep it secure etc. Initiatives like PassKey, ApplePay, TouchID etc. have been a huge win for security and privacy.

I don't want to require everyone to do that. I'm fine if others are willing to accept the risks of centralization of identify, payment, and apps into a single device. I understand the benefits you say are true for many people.

I don't want to be forced into that model because I think it's too risky. I think YubiKeys and other devices which require physical device attachment to use to be too risky when I know other solutions exist (see a parallel comment, or below).

I want to teach my kids that if a phone is asking for permission, asking to verify id, asking to read complex terms of services, then you must be careful, and preferably not trust them. The current model is "identify yourself whenever the computer asks" and "click I Agree", which seems open to all sorts of abuse of power and trust.

How many people know they are giving up their rights to a trial in favor of forced arbitration? How many read the license which says to email 'law@example.com' to not waive that right? How many are able to understand the relevant issue? Effectively zero. Are high schools going to start teaching contract law so students are able to understand what they are expected to sign? No.

I also think switching to 2FA and passkeys empowers the Google and Apple duopoly. What happens if you lose your phone? How do you reestablish your passkeys?

"Simple. In your new phone, log back in to your Google or Apple account", right?

And if Google or Apple shuts down your account for some reason?

"Umm, make backups? Also have a YubiKey?"

That's a huge lock-in for the sort of people who would otherwise store their passwords in a cleartext file. At the very least everyone should be able to let their bank or other trust third-party store a copy of the end-to-end encrypted database, and that bank or third-party should have an enforceable legal obligation to store, maintain, and provide that encrypted database, and that new phones can restore from this database without needing Apple or Google authorization, after the person has physically visited the bank or police station and identified themselves sufficiently.

And if I say I want something more secure and more portable than a YubiKey to log in?

My bank login device has had one change of AAA batteries in about 7 years. It has had zero updates, because it is not programmable. It uses a camera to read something like a QR code, a screen to read the requested task, a number pad to enter a PIN, and I can read the response code on the screen, to enter into the computer. It can work with any device, even ones without available plugs.

(And my bank is legally responsible for ensuring the security level is enough, and updating if it is not. Apple is not. Google is not.)

While I love it for bank login (it's the orange one at https://www.sparbankenskane.se/privat/digitala-tjanster/sake... ) I also don't want that for all my services!

If I need to pull it out, I know that I'm doing something that requires extra attention and care. The rituals needed for different levels of authorization should be very different, to make it hard to get confused about what you are doing. I also have the ability to physically leave my higher authentication devices at home while I'm out for the day.

(UPDATE: acdha correctly pointed out the phishing attack possible in this approach. I do not know what the bank does to protect against phishing. But since this is a low-use service, which is unlikely to be targeted, and I am fastidious about double-checking, it seems like a low risk issue. Security through diversity.)

Why should I trust ApplePay's privacy more than I do my bank's? Is ApplePay required to follow the same Swedish privacy restrictions that my bank does? Is ApplyPay equally liable in case of errors? Can the Swedish government audit how ApplePay works and confirm it complies to the same level of privacy as my bank?

Every time I look into it, it seems the answers are always "no." Maybe it's changed?

Basically, I trust international companies who have abused their monopoly position with my security and privacy far less than I trust the Swedish government.

Post reply on HN