Doesn’t it require a separate process to be using the cryptographic algorithm in the first place in order to fill the cache in question?
If it’s done in-process of a malicious app that you’re running, why wouldn’t the app just steal your password and avoid all of this in the first place?
An efficient and fast version of this in Javascript would be worrisome. But as-is it’s not clear if this can be optimized to go faster than 1-2 uninterrupted hours of processing, so hopefully that doesn’t end up being the case.
Doesn’t it require a separate process to be using the cryptographic algorithm in the first place in order to fill the cache in question?
Yes, that’s my understanding. I haven’t looked at the code, but their high level explanation sounds like their app is making calls to an API which could result in the under-the-hood crypto “service” pulling the keys into the cache, and there’s an element of luck to whether they snag portions of the keys at that exact moment. So it seems like the crafted app doesn’t have the ability to manipulate the crypto service directly, which makes sense if this is only a user-land app without root privileges.
why wouldn’t the app just steal your password and avoid all of this in the first place?
I believe it would be due to the app not having root privileges, and so being constrained with going through layers of abstraction to get its crypto needs met. I do not know the exact software architecture of iOS/macOS, but I guarantee there’s a notion of needing to call an API for these types things. For instance, if your app needs to push/pull an object it owns in/out of iCloud, you’d call the API with a number of arguments to do so. You would not have the ability to access keys directly and perform the encrypt/decrypt all by yourself. Likewise with any passwords, you would likely instead make an API call and the backing code/service would have that isolated/controlled access.
Doesn’t it require a separate process to be using the cryptographic algorithm in the first place in order to fill the cache in question?
If it’s done in-process of a malicious app that you’re running, why wouldn’t the app just steal your password and avoid all of this in the first place?
An efficient and fast version of this in Javascript would be worrisome. But as-is it’s not clear if this can be optimized to go faster than 1-2 uninterrupted hours of processing, so hopefully that doesn’t end up being the case.
Yes, that’s my understanding. I haven’t looked at the code, but their high level explanation sounds like their app is making calls to an API which could result in the under-the-hood crypto “service” pulling the keys into the cache, and there’s an element of luck to whether they snag portions of the keys at that exact moment. So it seems like the crafted app doesn’t have the ability to manipulate the crypto service directly, which makes sense if this is only a user-land app without root privileges.
I believe it would be due to the app not having root privileges, and so being constrained with going through layers of abstraction to get its crypto needs met. I do not know the exact software architecture of iOS/macOS, but I guarantee there’s a notion of needing to call an API for these types things. For instance, if your app needs to push/pull an object it owns in/out of iCloud, you’d call the API with a number of arguments to do so. You would not have the ability to access keys directly and perform the encrypt/decrypt all by yourself. Likewise with any passwords, you would likely instead make an API call and the backing code/service would have that isolated/controlled access.