Pointer authentication code - 편집 역사

2025년 6월 29일 (일) 08:40에 Ahn9807님의 편집

2025-06-29T08:40:06Z

← 이전 판		2025년 6월 29일 (일) 08:40 판
3번째 줄:		3번째 줄:

	== 개요 ==		== 개요 ==
	Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 보안 기법으로, 포인터를 사용하기 전에 이를 ~~인증하기 위해 사용된다~~. ~~ARM PAC은 Cherry비슷한 Capability~~-based ~~isolation환경을~~ Application과 ~~Kernel모두에게 제공한다~~.		Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 하드웨어 보안 기법으로, 포인터를 사용하기 전에 이를 인증하여 메모리 안전성을 보장한다. PAC는 Cherry와 유사한 capability-based isolation 환경을 제공하여, Application과 Kernel 모두에서 포인터 무결성을 보장받을 수 있다. 이는 특히 Return-Oriented Programming (ROP), Use-After-Free(UAF), 버퍼 오버플로우 등 현대의 다양한 메모리 공격 기법에 대한 효과적인 방어 수단으로 활용된다.

	== PAC ==		== PAC ==
	[[Return oriented programming]]과 같은 공격을 방어하기 ~~위해서~~, Pointer address의 [[무결성]](Integrity)를 ~~체크하는 하드웨어적인~~ [[SFI]]방식을 제공한다. ~~이를 통해서~~ 포인터가 ~~사용되기~~ 전에 ~~무결성을 체크하기 때문에~~, ~~포인터를 안전하게 사용할 수 있게 된다. 콘텍스트에는 base pointer address와 같은 것들이 사용된다~~.		[[Return oriented programming]]과 같은 공격을 방어하기 위해, 하드웨어 수준에서 Pointer address의 [[무결성]](Integrity)를 검증하는 [[SFI]](Software Fault Isolation) 방식을 제공한다. 이 방식을 통해 포인터가 메모리 접근 전에 정당한지를 하드웨어가 판단하고, 비정상일 경우 접근을 차단한다.

	~~하드웨어는 64bit에서 사용되지 않았던 top bit들에 pointer가~~ 생성될 당시 사용된 ~~Context와 임의의 key를 통해서 생성된~~ [[Message ~~autentication~~ code]]를 ~~저장한다~~. ~~포인터에 접근할때~~, ~~key와 context가 다르면 포인터에 대한 접근이~~ fault를 ~~발생시키기 때문에 안전하게~~ ROP, Spatial~~, Temporal과 같은 Heap~~ memory ~~bug들을 예방할 수 있다~~.		PAC는 포인터가 생성될 때, 사용된 콘텍스트(예: 함수 호출 시의 base pointer, stack pointer 등)와 암호화된 비밀 키를 바탕으로 [[Message authentication code]]를 생성하고, 포인터의 상위 비트에 이 정보를 삽입한다. 이후 포인터가 다시 사용될 때, 동일한 키와 콘텍스트를 통해 무결성 확인을 수행하며, 불일치 시 하드웨어 fault를 발생시킨다. 이러한 방식은 특히 ROP chain 탐지, Spatial 및 Temporal memory corruption 예방에 효과적이다.

	== PAC Instruction ==		== PAC Instruction ==
	<syntaxhighlight lang=asm>		<syntaxhighlight lang="asm">
	<function prologue>		<function prologue>
	paciasp ; sign (lr=x30)		paciasp ; sign (lr=x30) - SP를 기반으로 PAC 생성
	stp fp, lr, [sp, #0] ; ~~store lr~~		stp fp, lr, [sp, #0] ; frame pointer와 link register를 저장
	<function body>		<function body>
	<function epilogue>		<function epilogue>
	ldp fp, lr, [sp, #0] ; ~~load lr~~		ldp fp, lr, [sp, #0] ; 저장된 값 복원
	autiasp ; authentication		autiasp ; authentication
	ret ; ~~ret~~		ret ; 함수 복귀
			</syntaxhighlight>

			* '''PAC_A_B''': 레지스터 B에 있는 포인터에 대해 A 키를 사용하여 PAC를 생성. 예: PACIASP는 Instruction key (IA)로 SP 기반 인증.
			* '''AUT_A x''': A 키를 사용해 x 레지스터의 포인터 인증을 수행. 실패 시 fault 발생.
			* '''XPAC x''': 인증 실패 시 PAC를 제거해 포인터를 복원(의심 상황 진단용으로 사용).
			* '''PAC-aware Load/Store 명령어''':
			** ARMv8.3-A부터 도입된 Load/Store 명령어 확장으로, PAC가 적용된 포인터를 자동으로 인증하면서 로드하거나 저장할 수 있다.
			** 주로 pointer-authenticated 구조체나 함수 포인터 테이블 등에서 유용하게 사용된다.
			** 주요 명령어 예시는 다음과 같다:
			*** '''LDRAA Rt, [Rn]''': authenticated address를 로드하고, 인증이 성공하면 Rt에 값을 저장.
			*** '''LDG Rt, [Rn]''': tagged pointer를 인증하고 로드.
			*** '''STG Rt, [Rn]''': 인증된 pointer를 메모리에 저장.

			<syntaxhighlight lang="asm">
			; PAC된 포인터를 로드하는 예시
			ldraa x0, [x1] ; x1이 가리키는 주소에서 PAC 인증된 값을 x0에 로드

			; PAC된 포인터를 저장하는 예시
			paciza x2 ; x2에 대한 PAC 생성 (IA key 사용)
			stg x2, [x3] ; PAC된 x2 포인터를 메모리에 저장
	</syntaxhighlight>		</syntaxhighlight>

	~~PAC은 사용하기 위해선 반드시 Assembler혹은 Compiler의 도움을 받아야 한다. 즉, [[Transparent]]한 솔루션이 아니다.~~
	* PAC_A_B: B레지스터의 Pointer autentication code를 A키를 이용하여서 만들어내는 어셈블러이다. e.g., PACIASP는 IA (Instruction key)로 SP레지스터를 암호화. 키에 대한 자세한 설명은 메뉴얼을 참고.
	* AUT_A x: 키 A를 사용하여서, x레지스터에 대한 Athentication을 체크한다. 만약 틀릴경우에는 fault가 발생한다.
	* 그외에 load, store에 사용되는 명령어가 따로 있다.

	== 장점 ==		== 장점 ==
	* ~~하드웨어의 가속을 이용하여서 SFI를 효율적으로 강력하게~~ 사용할 수 있음		* 하드웨어 기반 인증으로 기존 Software-only 방식보다 빠르고 강력한 포인터 보호를 제공
			* 기존의 PAC-enabled 바이너리는 ARM TrustZone과 함께 사용할 경우 효과적인 격리 구조를 구현할 수 있음
			* 기존 공격 방식(RSP, heap spraying 등)의 무력화를 유도하며, ROP gadget 연결 시도에 대해 실패 가능성을 높임

	== 단점 ==		== 단점 ==
	* ~~추가적인 Compiler의 도움을 받아야 함~~		* PAC는 컴파일 타임 혹은 링커 단계에서 적용되므로 기존 바이너리에는 적용이 불가능하며, 소스 레벨에서의 수정 혹은 설정이 요구됨
	* ~~Performance critical한 컴포넌트에 적용시키기에는 still~~, ~~overhead를 무시할~~ 수 ~~없음. e.g.~~, SPEC ~~CPU 2006에서 sjeng벤치마크의 결과가 대략 3배 정도로 뛰기도 함. NaCL과 같은~~ Software~~-based isolation기법보다 느림. 이는 하드웨어가 빠르더라도, 컴파일러 기반의 체크 로직 추가가 어떤 오버헤드를 가져올~~ 수 ~~있는지를 모여주는 예시임.~~		* PAC를 사용하기 위해서는 반드시 컴파일러 또는 어셈블러의 지원이 필요하다. 따라서 이는 [[Transparent]]한 방어 기법이 아니며, 코드 수준의 명시적인 구현 혹은 설정이 요구됨
	* ~~PAC을 우회할 수 있는 취약점들이 존재함~~		* 성능 저하가 발생할 수 있으며, 특히 Performance-critical 컴포넌트에서는 눈에 띄는 오버헤드가 발생할 수 있음
			** 예: SPEC CPU2006의 sjeng 벤치마크 기준으로 PAC 도입 후 성능이 3배까지 저하된 사례가 보고됨
			* [[NaCl]]이나 WebAssembly 기반의 Software Isolation에 비해 여전히 유연성에서 한계를 보일 수 있음
			* 일부 연구 결과에 따르면, PAC 우회를 시도하는 취약점(exploit primitive)도 존재하므로 절대적인 방어 수단은 아님

	== 참고 ==		== 참고 ==
	# Limitations and Opportunities of Modern Hardware Isolation Mechanisms (Usenix ATC'24)		# ''Limitations and Opportunities of Modern Hardware Isolation Mechanisms'' (Usenix ATC'24)
	# https://velog.io/@pensieveview/Pointer-authentication		# [https://velog.io/@pensieveview/Pointer-authentication velog.io/@pensieveview/Pointer-authentication]
			# ARM Architecture Reference Manual for ARMv8-A, Section on Pointer Authentication
			# [https://blog.trailofbits.com/2020/11/10/untangling-pointer-authentication-on-ios/ PAC in Apple A12 and M1 Chips - Trail of Bits]

2024년 9월 4일 (수) 03:06에 Ahn9807님의 편집

2024-09-04T03:06:59Z

← 이전 판		2024년 9월 4일 (수) 03:06 판
6번째 줄:		6번째 줄:

	== PAC ==		== PAC ==
	[[Return ~~oridented~~ programming]]과 같은 공격을 방어하기 위해서, Pointer address의 [[무결성]](Integrity)를 체크하는 하드웨어적인 [[SFI]]방식을 제공한다. 이를 통해서 포인터가 사용되기 전에 무결성을 체크하기 때문에, 포인터를 안전하게 사용할 수 있게 된다. 콘텍스트에는 base pointer address와 같은 것들이 사용된다.		[[Return oriented programming]]과 같은 공격을 방어하기 위해서, Pointer address의 [[무결성]](Integrity)를 체크하는 하드웨어적인 [[SFI]]방식을 제공한다. 이를 통해서 포인터가 사용되기 전에 무결성을 체크하기 때문에, 포인터를 안전하게 사용할 수 있게 된다. 콘텍스트에는 base pointer address와 같은 것들이 사용된다.

	하드웨어는 64bit에서 사용되지 않았던 top bit들에 pointer가 생성될 당시 사용된 Context와 임의의 key를 통해서 생성된 [[Message autentication code]]를 저장한다. 포인터에 접근할때, key와 context가 다르면 포인터에 대한 접근이 fault를 발생시키기 때문에 안전하게 ROP, Spatial, Temporal과 같은 Heap memory bug들을 예방할 수 있다.		하드웨어는 64bit에서 사용되지 않았던 top bit들에 pointer가 생성될 당시 사용된 Context와 임의의 key를 통해서 생성된 [[Message autentication code]]를 저장한다. 포인터에 접근할때, key와 context가 다르면 포인터에 대한 접근이 fault를 발생시키기 때문에 안전하게 ROP, Spatial, Temporal과 같은 Heap memory bug들을 예방할 수 있다.

Ahn9807: Ahn9807님이 Pointer autehntication code 문서를 Pointer authentication code 문서로 이동했습니다

2024-09-04T03:04:59Z

Ahn9807님이 Pointer autehntication code 문서를 Pointer authentication code 문서로 이동했습니다

← 이전 판	2024년 9월 4일 (수) 03:04 판
(차이 없음)

Ahn9807: 새 문서: 분류: 하드웨어 기반 보안 분류: ARM == 개요 == Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 보안 기법으로, 포인터를 사용하기 전에 이를 인증하기 위해 사용된다. ARM PAC은 Cherry비슷한 Capability-based isolation환경을 Application과 Kernel모두에게 제공한다. == PAC == Return oridented programming과 같은 공격을 방어하기 위해서, Pointer address의 무결성(Integrity)를...

2024-09-04T03:04:28Z

새 문서: 분류: 하드웨어 기반 보안 분류: ARM == 개요 == Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 보안 기법으로, 포인터를 사용하기 전에 이를 인증하기 위해 사용된다. ARM PAC은 Cherry비슷한 Capability-based isolation환경을 Application과 Kernel모두에게 제공한다. == PAC == Return oridented programming과 같은 공격을 방어하기 위해서, Pointer address의 무결성(Integrity)를...

새 문서

[[분류: 하드웨어 기반 보안]]
[[분류: ARM]]

== 개요 ==
Pointer Authentication Code (PAC)는 ARMv8.3 (AArch64)에서 도입된 보안 기법으로, 포인터를 사용하기 전에 이를 인증하기 위해 사용된다. ARM PAC은 Cherry비슷한 Capability-based isolation환경을 Application과 Kernel모두에게 제공한다.

== PAC ==
[[Return oridented programming]]과 같은 공격을 방어하기 위해서, Pointer address의 [[무결성]](Integrity)를 체크하는 하드웨어적인 [[SFI]]방식을 제공한다. 이를 통해서 포인터가 사용되기 전에 무결성을 체크하기 때문에, 포인터를 안전하게 사용할 수 있게 된다. 콘텍스트에는 base pointer address와 같은 것들이 사용된다.

하드웨어는 64bit에서 사용되지 않았던 top bit들에 pointer가 생성될 당시 사용된 Context와 임의의 key를 통해서 생성된 [[Message autentication code]]를 저장한다. 포인터에 접근할때, key와 context가 다르면 포인터에 대한 접근이 fault를 발생시키기 때문에 안전하게 ROP, Spatial, Temporal과 같은 Heap memory bug들을 예방할 수 있다.

== PAC Instruction ==
<syntaxhighlight lang=asm>
<function prologue>
paciasp ; sign (lr=x30)
stp fp, lr, [sp, #0] ; store lr
<function body>
<function epilogue>
ldp fp, lr, [sp, #0] ; load lr
autiasp ; authentication
ret ; ret
</syntaxhighlight>

PAC은 사용하기 위해선 반드시 Assembler혹은 Compiler의 도움을 받아야 한다. 즉, [[Transparent]]한 솔루션이 아니다.
* PAC_A_B: B레지스터의 Pointer autentication code를 A키를 이용하여서 만들어내는 어셈블러이다. e.g., PACIASP는 IA (Instruction key)로 SP레지스터를 암호화. 키에 대한 자세한 설명은 메뉴얼을 참고.
* AUT_A x: 키 A를 사용하여서, x레지스터에 대한 Athentication을 체크한다. 만약 틀릴경우에는 fault가 발생한다.
* 그외에 load, store에 사용되는 명령어가 따로 있다.

== 장점 ==
* 하드웨어의 가속을 이용하여서 SFI를 효율적으로 강력하게 사용할 수 있음

== 단점 ==
* 추가적인 Compiler의 도움을 받아야 함
* Performance critical한 컴포넌트에 적용시키기에는 still, overhead를 무시할 수 없음. e.g., SPEC CPU 2006에서 sjeng벤치마크의 결과가 대략 3배 정도로 뛰기도 함. NaCL과 같은 Software-based isolation기법보다 느림. 이는 하드웨어가 빠르더라도, 컴파일러 기반의 체크 로직 추가가 어떤 오버헤드를 가져올 수 있는지를 모여주는 예시임.
* PAC을 우회할 수 있는 취약점들이 존재함

== 참고 ==
# Limitations and Opportunities of Modern Hardware Isolation Mechanisms (Usenix ATC'24)
# https://velog.io/@pensieveview/Pointer-authentication