[flagged]
Did you actually look at the paper? It’s extremely technical. I can’t imagine the logo took even 1% of the time they spent on this.
New vuln in Apple M-series allowing secret keys extraction can't be patched
111–120 of 145 posts
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#112Google, in 2021 [0]: > While the PoC demonstrates the JavaScript Spectre attack against Chrome 88's V8 JavaScript engine on an Intel Core i7-6500U 'Skylake' CPU on Linux, Google notes it can easily be tweaked for other CPUs... It was even successful on Apple's M1 Arm CPU... And Augury [1] in 2022 also affected Apple's A14 and M1 chips. So have Apple been attempting to mitigate and failing, or ignoring the issue? Sure…
Some of the authors of this paper worked on Augury, too, but note that this is a different angle than Spectre: that was speculative execution (running instructions before knowing which way a branch would evaluate) and this is data prefetching.
The reason this keeps coming up is that it isn’t a single issue but a class of attacks exploiting performance features, and attackers are getting more sophisticated as smart people figure out new techniques. Chip designers have been adjusting but are trying not to throw out the last couple decades of performance improvements, too.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#113[flagged]
Did you actually look at the paper? It’s extremely technical. I can’t imagine the logo took even 1% of the time they spent on this.
Yes. I merely meant that I believe blowing those things out of proportion on purpose isn't helping anybody. The reality of vulns like this is that they don't affect the majority of normal people. Everybody wants to be the next cloudbleed.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#114Earlier 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.
All Apple devices allow you to use it for important keys:
https://developer.apple.com/documentation/security/certifica...
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#115Earlier quoted context omitted.
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…
> How do they protect against phishing?
The same way they minimize the vulnerability when running on an exploited Windows machine?
Even if I log in, via a MITM attack, all they can do is read my account history.
Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes.
Still, you make a very valid point, and I thank you for pointing out the flaw in my understanding.
I still have a very deep distrust about centralizing identification, payment, and apps on a single device, and strongly dislike the inability to have physically very distinct trust levels.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#116> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?
Speculation is required to get even close to the single-thread throughput expected of any modern CPU for anything worth running on a general purpose CPU. The problem is that there is no formal specified model to reason over side-channels not even just for timing side-channels. Most ISAs doesn't specify the time it takes execute instructions.
Lets assume I multiply two 64bit numbers. The CPU could just do it the same way every time and the worst-case has 4 cycles latency. It may also track if one of the factors is zero and dynamically replace the multiplication with a zeroing idiom that "executes" in 0 cycles when the scheduler learns that that either input is zero as an extreme example.
Less radical it could track if the upper halves of registers are zero to fast-path smaller multiplications (e.g. 32bit x 32bit -> 64bit) and shave off a cycle. IIRC some PowerPC chips did that, but for the second argument only. The ISA allowed it.
A realistic example are CPUs with data-dependent latency shift/rotate instructions. What do you do if an ISA doesn't specify if shift/rotate is constant time, but every implementation of it so far did it in constant time? Do you slowly emulate it out of paranoia that a future implementation may have variable latency? An other real-world example of this would be FPUs that have higher latency for denormalised numbers its just not relevant to (most) cryptographic algorithms.
How the fuck are you supposed to build anything secure, useful, and fast enough from that?
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#117> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?
It is bad, it is required for performance reasons. The questions is what could be the solution going forward, which is going to be a huge change anyway. I do not see a way out of this with our current architectures.
Neither block ciphers, nor stream ciphers, nor common public key algorithms (RSA, Ed25519) need or even profit from this. They just need fast access to the register-register math, maybe loop sequentially through all members of a fixed sized array a fixed number of times. The only thing those implementing such algorithms would probably like having is a few kiB of safe to access scratchpad memory for code and data. On entry to the crypto code copy the code and data there, enable a constant time mode for compute instructions and run the algorithm at full speed without worrying.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#118Earlier quoted context omitted.
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.
My bank's terms of services say they are not responsible for flaws in the mobile phone or privacy issues in the store.
If there is a vulnerability, who pays for fixing it? Who pays for the new phones?
Of course the credit card companies and banks don't want to be responsible. They currently aren't, and they don't want to take it on.
Why should the regulators care yet? Using a mobile phone is still under the fiction that it's an optional functionality, where the user has agreed to take on the risk themselves, in exchange for better convenience and non-essential services.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#119Earlier quoted context omitted.
> 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…
> How do they protect against phishing? The same way they minimize the vulnerability when running on an exploited Windows machine? Even if I log in, via a MITM attack, all they can do is read my account history. Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes. Still, you make a…
> Actually making changes requires further authorization. When I make a payment the screen asks me to confirm the amount I'm about to pay. The same applies to other security sensitive changes.
That’s a good answer, too, especially of that custom message can be large enough to display the name & amount. Anything to jar people out of the “I thought I was sending $100 to the cable TV company, not $6,000 to someone in India” autopilot state.
I generally agree with your larger point and wish that banks would make it easier to do things like setup a Yubikey and require it be used on any transaction over a certain amount. I’ve never in my life needed to make a large transaction where I wouldn’t have been able to grab a token from my safe to approve it, and at some point delay becomes a security feature since it give the bank staff time to do things like call you and make sure you really intended to do something.
Re: New vuln in Apple M-series allowing secret keys extraction can't be patched
#120Earlier quoted context omitted.
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.
Hey, this is completely up to you. nobody is trying to steal your apple pay. this is merely the parent commenter's belief that they would should use different apps to reduce the risk vector when secrets are stolen. no reason to completely ballistic.
Thanks, though I would say "different physical devices" not "different apps".
This also gets into e-waste issues. I really don't want multiple phones, and in any case, consumer phones are expected to be replaced every few years. A friend has an old iPhone which still works, but the local transit system's app no longer supports it. My bank's mobile app requires Android 7, etc.