Does iPhone support hardware-accelerated AES Encryption?

Yes.

As of 4.3, if the message has >64 blocks (i.e. 1024 bytes), the CCCrypt function for AES will use the hardware-accelerated implementation. (This is done by ioctling with /dev/aes_0, BTW.)

Besides AES, SHA-1 is also hardware-accelerated when the input is > 4096 bytes.

The whole point of an API is that you don't need to care about the implementation details that back it. The implementor (Apple, in this case) will use whatever implementation gives the best performance and energy usage characteristics on whatever hardware is in use. That might be a hardware implementation, or it might be a software implementation, it might depend on the block size for which you are calling the function.

Does iPhone support hardware-accelerated AES Encryption?

It depends on the iPhone version and hardware, but mostly YES in 2015.

Apple uses it for the quick "remote wipe" feature for managed devices. The idea is everything is encrypted, and the keys are stored in a keybag backed by effaceable storage ("effaçable" is French for "erasable"). For more information, see Jean-Baptiste Bédrune and Jean Sigwald iPhone data protection in depth; and Dino Zavi's Apple iOS 4 Security Evaluation.

The circuit is placed on the DMA datapath between storage and memory so anything traversing the path is encrypted or decrypted.

If the device is lost or stolen, then a command can be sent to the device to erase the keybag holding the keys used for encryption and decryption. Because the keybag is backed by effaceable storage, the keys don't move around due to wear leveling.

It appears Apple provides hardware accelerated AES from at least two sources on iOS devices. Both are wrapped by Apple's CommonCrypto framework. At least one appears to be available to the programmer without the need for CommonCrypto.

First hardware accelerated source

The first source is standard ARM crypto available in ARMv8 and above. The instructions are available as both C/C++ intinsics and assembly when __ARM_FEATURE_CRYPTO is defined:

$ clang++ -arch arm64 -dM -E - < /dev/null | sort | egrep -i '(arm|aarch|neon)'#define __AARCH64EL__ 1#define __AARCH64_SIMD__ 1#define __ARM64_ARCH_8__ 1#define __ARM_64BIT_STATE 1#define __ARM_ACLE 200#define __ARM_ALIGN_MAX_STACK_PWR 4#define __ARM_ARCH 8#define __ARM_ARCH_ISA_A64 1#define __ARM_ARCH_PROFILE 'A'#define __ARM_FEATURE_CLZ 1#define __ARM_FEATURE_CRYPTO 1#define __ARM_FEATURE_DIV 1#define __ARM_FEATURE_FMA 1#define __ARM_FEATURE_UNALIGNED 1#define __ARM_FP 0xe#define __ARM_FP16_FORMAT_IEEE 1#define __ARM_FP_FENV_ROUNDING 1#define __ARM_NEON 1#define __ARM_NEON_FP 7#define __ARM_NEON__ 1#define __ARM_PCS_AAPCS64 1#define __ARM_SIZEOF_MINIMAL_ENUM 4#define __ARM_SIZEOF_WCHAR_T 4#define __aarch64__ 1#define __arm64 1#define __arm64__ 1

By the way, when __ARM_FEATURE_CRYPTO is defined, you should have access to hardware accelerated SHA-1 and SHA-2, also.

Second hardware accelerated source

The second source appears to be custom, and its present in ARMv7s and below. I'm not sure how to get to this crypto (maybe opensource.apple.com has the answer):

$ clang++ -arch armv7s -dM -E - < /dev/null | sort | egrep -i '(arm|aarch|neon|crc|crypto)'#define __ARMEL__ 1#define __ARM_ARCH 7#define __ARM_ARCH_7S__ 1#define __ARM_ARCH_EXT_IDIV__ 1#define __ARM_NEON 1#define __ARM_NEON__ 1#define __ARM_SIZEOF_MINIMAL_ENUM 4#define __ARM_SIZEOF_WCHAR_T 4#define __ARM_VFPV4__ 1#define __arm 1#define __arm__ 1

And:

$ clang++ -arch armv7 -dM -E - < /dev/null | sort | egrep -i '(arm|aarch|neon|crc|crypto)'#define __ARMEL__ 1#define __ARM_ARCH 7#define __ARM_ARCH_7A__ 1#define __ARM_ARCH_PROFILE A#define __ARM_NEON 1#define __ARM_NEON__ 1#define __ARM_SIZEOF_MINIMAL_ENUM 4#define __ARM_SIZEOF_WCHAR_T 4#define __ARM_VFPV3__ 1#define __arm 1#define __arm__ 1

A related question is Which hardware chip/vendor does Apple use for its hardware-accelerated AES/SHA-1 encryption?

Here's some code we are using for iOS. It test for runtime support of ARM Crypto instructions. Because the code is intrinsic-based, the same code is used for iOS, Linux, Windows Phone and Windows Store. In the case of iOS, its used when -arch arm64 is specified.

#if (BOOL_ARM32 || BOOL_ARM64) && (/* other support tests */)# define BOOL_ARM_CRYPTO_INTRINSICS_AVAILABLE 1#endif...static bool TryCrypto(){#if (BOOL_ARM_CRYPTO_INTRINSICS_AVAILABLE)# if defined(_WIN32) || defined(_WIN64)    __try    {        // AES encrypt and decrypt        static const uint8x16_t data = vdupq_n_u8(0), key = vdupq_n_u8(0);         uint8x16_t r1 = vaeseq_u8(data, key);        uint8x16_t r2 = vaesdq_u8(data, key);    }    __except (EXCEPTION_EXECUTE_HANDLER)    {        return false;    }    return true;# else    // longjmp and clobber warnings. Volatile is required.    volatile bool result = true;    SigHandler oldHandler = signal(SIGILL, SigIllHandlerCrypto);    if (oldHandler == SIG_ERR)        result = false;    if (setjmp(s_jmpNoCrypto))        result = false;    else    {        // AES encrypt and decrypt        static const uint8x16_t data = vdupq_n_u8(0), key = vdupq_n_u8(0);         uint8x16_t r1 = vaeseq_u8(data, key);        uint8x16_t r2 = vaesdq_u8(data, key);    }    signal(SIGILL, oldHandler);    return result;# endif#else    return false;#endif}

And here's what it looks like from the command line during a compile:

clang++ -DNDEBUG -g2 -O3 -fPIC -pipe -Wall -miphoneos-version-min=7 -arch arm64 -stdlib=libc++ -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk-c cpu.cppcpu.cpp:438:14: warning: unused variable 'r1' [-Wunused-variable]                uint8x16_t r1 = vaeseq_u8(data, key);                           ^cpu.cpp:439:14: warning: unused variable 'r2' [-Wunused-variable]                uint8x16_t r2 = vaesdq_u8(data, key);                           ^2 warnings generated.