HackIT is an annual cybersecurity conference that gathers the best technical researchers and top players in the cybersecurity industry to explore cutting-edge technologies together. In 2018, HackIT focused on the use of blockchain technology. Join our community: Website - https://hacken.live/hackit-slideshare Twitter - https://hacken.live/twitter_hackit Facebook - https://hacken.live/facebook_hackit Instagram - https://hacken.live/instagram_hackit Reddit - https://hacken.live/reddit Telegram community - https://hacken.live/tg-hackit #hackit #cybersecurity #blockchain #hacking

1. HackIT 4.0, Kyiv
Is ARMv8.3 the end of ROP?
Dima Kovalenko

2. HackIT 4.0, Kyiv
Dima Kovalenko
kov4l3nko@gmail.com
iOS/Android reverse
engineer, security
researcher

3. Agenda
• ARMv8.3
• Pointer authentication code (PAC)
• QARMA
• Possible attacks
• What about the real world?

4. ARMv3.8

5. ARMv8.3
• It’s an optional extension of ARMv8
• It’s for AArch64 mode only.
• It adds, among other things, 46 new machine instructions to
implement signed pointers
• It’s backward compatible with the standard ARMv8 instruction
set

6. Pointer authentication code
(PAC)

7. Pointer authentication code
(PAC)
• ARMv8.3 introduces Pointer Authentication Code (PAC)
• It’s implemented if at least one of system registers
ID_AA64ISAR1_EL1.APA, ID_AA64ISAR1_EL1.API,
ID_AA64ISAR1_EL1.GPA, or ID_AA64ISAR1_EL1.GPI is 0b0001

8. Pointer authentication code
(PAC)
• PAC is stored in upper bits of a pointer:
Bit range Description
0…TCR_ELx.TnSZ-1 Actually the address
TCR_ELx.TnSZ…54 PAC
55 n
56…63 If n is 1, the the bit range holds address tag;
else it holds PAC

9. Pointer authentication code
(PAC)
• PAC is calculated according the following general pattern:
Pointer
Modifier
Key
P(…) PAC + Pointer
• If ID_AA64ISAR1_EL1.APA is 0b0001, then P(…) is QARMA;
otherwise it’s IMPLEMENTATION DEFINED
• Anyway the resulting PAC+Pointer is not a valid pointer!

10. Pointer authentication code
(PAC)
• The specifications defines five 128 bit keys:
• API{A,B}Key_EL1 (for instruction pointers) is concatenation of the
register values API{A,B}KeyHi_EL1:API{A,B}KeyLo_EL1.
• APD{A,B}Key (for data pointers) is the concatenation of the
register values APD{A,B}KeyHi_EL1:APD{A,B}KeyLo_EL1.
• APGAKey (for data) is the concatenation of the register values
APGAKeyHi_EL1:APGAKeyLo_EL1
• The keys are placed in *_EL1 registers and not accessible in EL0
(user mode)

11. Pointer authentication code
(PAC)
• The keys are expected to be ephemeral (per process for EL0 and per
boot for EL1 to EL3)
• Key management, including generating good quality random
numbers, is the responsibility of the software (e.g. OS)
• Some ARMv8.3 instructions (PACIA, PACIA1716 etc) also need a 64
bit modifier to calculate PAC. Depending on the instruction it can be
SP, X16 or any Xn register.

12. Pointer authentication code
(PAC)
• In general, there are two groups of ARMv8.3 instructions:
• Basic pointer authentication instructions. Each of these
instructions only performs an operation that supports pointer
authentication.
• Combined instructions that include pointer authentication.
Each of these instructions combines a pointer authentication
with another operation that uses the authenticated pointer (e.g.
BRAA branches to a register, with pointer authentication).

13. Pointer authentication code
(PAC)
• There are, in turn, three subgroups of basic pointer
authentication instructions:
• Instructions that calculate/add PAC
• Instructions that authenticate/strip PAC. If authentication
fails, the upper bits of a pointer are corrupted and any
subsequent use of the pointer results in a Translation fault.
• Instructions that just strip PAC without authentication.

14. Pointer authentication code
(PAC)
• ARMv8.3 instructions are backward compatible with ARMv8
because for early SoC’s they all are encoded as HINT #0
(NOP) :)

15. Pointer authentication code
(PAC)
• An example. No stack protection:
; function prologue
SUB sp, sp, #0x40
STP x29, x30, [sp,#0x30]
ADD x29, sp, #0x30
…
; function epilogue
LDP x29,x30,[sp,#0x30]
ADD sp,sp,#0x40
RET

16. Pointer authentication code
(PAC)
• An example. The stack is protected with ARMv8.3:
; function prologue
PACIASP ; <=== calculate/add PAC to LR, use SP as a modifier
SUB sp, sp, #0x40
STP x29, x30, [sp,#0x30]
ADD x29, sp, #0x30
…
; function epilogue
LDP x29,x30,[sp,#0x30]
ADD sp,sp,#0x40
AUTIASP ; <== auth./strip PAC from LR, use SP as a modifier
RET

17. For more details on ARMv8.3 and PAC, see
• “ARM Architecture Reference Manual ARMv8, for ARMv8-A
architecture profile” by ARM team (https://developer.arm.com/docs/
ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-
architecture-profile)
• “ARMv8.3 Pointer Authentication” by Mark Rutland from ARM (https://
events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf)
• “Pointer Authentication on ARMv8.3” by Qualcomm team (https://
www.qualcomm.com/media/documents/files/whitepaper-pointer-
authentication-on-armv8-3.pdf)

18. QUARMA

19. QARMA
• The size of PAC depends of virtual memory address range, it is
between
• 11…31 bits when memory tagging is used
• 3…23 bits when memory tag is used
• Qualcomm considered existing crypto algorithms and rejected it
because of various reasons, e.g.
• SipHash is relatively slow and can make impact on latency
• PRINCE has a fixed-size input/output block, truncating can
make PAC predictable

20. QARMA
• QARMA was designed by Qualcomm to be fast and produce short
signatures if needed
• QARMA was carefully tested, including cryptanalysis tests
• Is it really safe? It’s hard to say for sure :)

21. For more details on QARMA, see
• “The QARMA Block Cipher Family” by Roberto Avanzi from
Qualcomm (https://eprint.iacr.org/2016/444.pdf)
(at least, check the section “4 Security Analysis”)

22. Possible attacks

23. Possible attacks
• Guessing and forging PAC values. Complexity depends on the
crypto algorithm. Theoretically, this attack must be hard for
QARMA.
• Pointer substitution attacks include various form of substituting
one authenticated pointer with another. Probably it’s possible.
Anyway, PAC should make finding ROP/JOB chains much harder.
• Key management concerns and key reuse attacks. Generating/
managing keys is software responsibility, so it depends on the
software.

24. Possible attacks
• Interpreters and Just-in-Time Compilation (JIT) can not be
protected by PAC (PAC does not protect again data-only attacks),
so it’s a very good attack vector. Maybe the best.

25. What about the real world?

26. What about the real world?
• ARMv8.3 supported by
• GCC, starting from version 7
• LLVM, starting from the commit https://github.com/llvm-mirror/
llvm/commit/af93d17e0c779e519918a892adb33608c6f9dfdb
• At the moment, the only widely known system on a chip with
ARMv8.3 support is Apple A12.
• It should prevent exploitation of memory corruption
vulnerabilities on the newest iPhone XS, XS Max, and XR, but…

27. What about the real world?
• …it looks like it doesn’t help.
• The details are not known
yet, so we are impatiently
waiting for the writeup from
@PanguTeam.

28. Links

29. Links
“ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile”
by ARM team (https://developer.arm.com/docs/ddi0487/latest/arm-architecture-
reference-manual-armv8-for-armv8-a-architecture-profile)
“ARMv8.3 Pointer Authentication” by Mark Rutland from ARM (https://
events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf)
“Pointer Authentication on ARMv8.3” by Qualcomm team (https://
www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-
on-armv8-3.pdf)
“The QARMA Block Cipher Family” by Roberto Avanzi from Qualcomm (https://
eprint.iacr.org/2016/444.pdf)

30. Questions?