replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

On multi-core platforms at least (and most new smartphones are multi-core), all the side-channel attacks on branch prediction and cache should work, as long as the attacker can access a clock with enough precision. The ARM architecture has a "cycle counter" that application code can use, but it has to be first enable from privileged code (kernel); see this answerthis answer. Native code is possible for apps starting with Android 2.3 (with the NDK).

I don't know if the cycle counter is enabled by default with Android; it is disabled in a freshly booted CPU, but Android uses a Linux kernel and the cycle counter is very convenient for a number of tasks, including implementing the gettimeofday() system call, so it is possible that the Linux kernel enables it. This should be tested.

IF the cycle counter is enabled, then chances are that the Java method System.nanoTime() may also return the same information, for pure Java apps. So going native might not even be necessary to pull off a cache-timing attack on Android.

Also, there can be other accurate clocks. For instance, the GPS API provides one, with Location.getElapsedRealtimeNanos().

Side-channel attacks on cache access have been demonstrated on common AES implementations (in lab conditions, but still demonstrated). There has been quite some work done on such attacks against cryptographic algorithm, but there is nothing here really specific to cryptography. It just happens that cryptographic algorithms uses keys and keys concentrate secrets; knowing the key reveals a lot of things, so keys are high-value targets. Also, all such attacks were researched by cryptographers, and cryptographers work on cryptographic algorithm. However, side-channel leaks may occur on just every single implementation of any algorithm, cryptographic or not. Usually, when encryption occurs in a device, it is because some confidential data is processed by that device, and all that processing, not just the encryption, may leak like crazy. The issue is real and all-encompassing.

Under these assumptions, one must assume that a lot of data can be inferred from an app, about what other apps do. Defending against local attackers, who run their code on the same hardware as you and at the same time, is hard.

On multi-core platforms at least (and most new smartphones are multi-core), all the side-channel attacks on branch prediction and cache should work, as long as the attacker can access a clock with enough precision. The ARM architecture has a "cycle counter" that application code can use, but it has to be first enable from privileged code (kernel); see this answer. Native code is possible for apps starting with Android 2.3 (with the NDK).

I don't know if the cycle counter is enabled by default with Android; it is disabled in a freshly booted CPU, but Android uses a Linux kernel and the cycle counter is very convenient for a number of tasks, including implementing the gettimeofday() system call, so it is possible that the Linux kernel enables it. This should be tested.

IF the cycle counter is enabled, then chances are that the Java method System.nanoTime() may also return the same information, for pure Java apps. So going native might not even be necessary to pull off a cache-timing attack on Android.

Also, there can be other accurate clocks. For instance, the GPS API provides one, with Location.getElapsedRealtimeNanos().

Side-channel attacks on cache access have been demonstrated on common AES implementations (in lab conditions, but still demonstrated). There has been quite some work done on such attacks against cryptographic algorithm, but there is nothing here really specific to cryptography. It just happens that cryptographic algorithms uses keys and keys concentrate secrets; knowing the key reveals a lot of things, so keys are high-value targets. Also, all such attacks were researched by cryptographers, and cryptographers work on cryptographic algorithm. However, side-channel leaks may occur on just every single implementation of any algorithm, cryptographic or not. Usually, when encryption occurs in a device, it is because some confidential data is processed by that device, and all that processing, not just the encryption, may leak like crazy. The issue is real and all-encompassing.

Under these assumptions, one must assume that a lot of data can be inferred from an app, about what other apps do. Defending against local attackers, who run their code on the same hardware as you and at the same time, is hard.

On multi-core platforms at least (and most new smartphones are multi-core), all the side-channel attacks on branch prediction and cache should work, as long as the attacker can access a clock with enough precision. The ARM architecture has a "cycle counter" that application code can use, but it has to be first enable from privileged code (kernel); see this answer. Native code is possible for apps starting with Android 2.3 (with the NDK).

I don't know if the cycle counter is enabled by default with Android; it is disabled in a freshly booted CPU, but Android uses a Linux kernel and the cycle counter is very convenient for a number of tasks, including implementing the gettimeofday() system call, so it is possible that the Linux kernel enables it. This should be tested.

IF the cycle counter is enabled, then chances are that the Java method System.nanoTime() may also return the same information, for pure Java apps. So going native might not even be necessary to pull off a cache-timing attack on Android.

Also, there can be other accurate clocks. For instance, the GPS API provides one, with Location.getElapsedRealtimeNanos().

Side-channel attacks on cache access have been demonstrated on common AES implementations (in lab conditions, but still demonstrated). There has been quite some work done on such attacks against cryptographic algorithm, but there is nothing here really specific to cryptography. It just happens that cryptographic algorithms uses keys and keys concentrate secrets; knowing the key reveals a lot of things, so keys are high-value targets. Also, all such attacks were researched by cryptographers, and cryptographers work on cryptographic algorithm. However, side-channel leaks may occur on just every single implementation of any algorithm, cryptographic or not. Usually, when encryption occurs in a device, it is because some confidential data is processed by that device, and all that processing, not just the encryption, may leak like crazy. The issue is real and all-encompassing.

Under these assumptions, one must assume that a lot of data can be inferred from an app, about what other apps do. Defending against local attackers, who run their code on the same hardware as you and at the same time, is hard.

Source Link
Tom Leek
  • 169.3k
  • 29
  • 340
  • 477

On multi-core platforms at least (and most new smartphones are multi-core), all the side-channel attacks on branch prediction and cache should work, as long as the attacker can access a clock with enough precision. The ARM architecture has a "cycle counter" that application code can use, but it has to be first enable from privileged code (kernel); see this answer. Native code is possible for apps starting with Android 2.3 (with the NDK).

I don't know if the cycle counter is enabled by default with Android; it is disabled in a freshly booted CPU, but Android uses a Linux kernel and the cycle counter is very convenient for a number of tasks, including implementing the gettimeofday() system call, so it is possible that the Linux kernel enables it. This should be tested.

IF the cycle counter is enabled, then chances are that the Java method System.nanoTime() may also return the same information, for pure Java apps. So going native might not even be necessary to pull off a cache-timing attack on Android.

Also, there can be other accurate clocks. For instance, the GPS API provides one, with Location.getElapsedRealtimeNanos().

Side-channel attacks on cache access have been demonstrated on common AES implementations (in lab conditions, but still demonstrated). There has been quite some work done on such attacks against cryptographic algorithm, but there is nothing here really specific to cryptography. It just happens that cryptographic algorithms uses keys and keys concentrate secrets; knowing the key reveals a lot of things, so keys are high-value targets. Also, all such attacks were researched by cryptographers, and cryptographers work on cryptographic algorithm. However, side-channel leaks may occur on just every single implementation of any algorithm, cryptographic or not. Usually, when encryption occurs in a device, it is because some confidential data is processed by that device, and all that processing, not just the encryption, may leak like crazy. The issue is real and all-encompassing.

Under these assumptions, one must assume that a lot of data can be inferred from an app, about what other apps do. Defending against local attackers, who run their code on the same hardware as you and at the same time, is hard.