I. 서론
현대 소프트웨어 개발에서 메모리 안전성은 보안의 핵심 요소로 자리잡고 있다. 특히, C/C++ 언어에서 발생하는 메모리 취약점은 다양한 보안 사고를 초래할 수 있다. 이러한 문제를 해결하기 위해 RUST 언어는 메모리 안전성을 보장하는 혁신적인 접근 방식을 제공하며, 최근 미국 NSA는 RUST 언어의 사용을 권장하고 있다. 본 연구는 RUST 언어를 기반으로 한 암호모듈의 검증 방법론을 제시하여, KCMVP의 요구사항(암호모듈 인터페이스, 중요보안매개변수 관리 등)을 충족시키는데 기여하고자 한다.
RUST 기반 암호모듈 안전성 검증을 위해서는 KCMVP의 요구사항을 충족시키기 위해 RUST 언어의 특성을 반영하여야 한다. 이를 위해 기본적으로 RUST 언어로 구현된 암호모듈의 취약성 예방, 규제(포맷) 준수, 신뢰성 확보가 가능한 검증규칙이 필요하며, 검증규칙에 따라 취약점을 분석할 도구가 필요하다. 따라서 본 논문에서는 RUST 언어의 특성을 반영한 검증규칙을 제안하고, 제안한 검증규칙을 기반으로 RUST 기반 암호모듈의 안전성을 평가할 수 있는 오픈소스 도구를 소개하고 이를 활용한 검증 방법론을 제안한다.
본 연구의 주요 목표는 다음과 같다.
1) KCMVP 표준을 준수하는 RUST 기반 암호 모듈 검증을 위한 최소 안전성 확보를 위한 요구사항을 제안, 이는 암호모듈의 신뢰성을 높이고, 보안 사고를 예방하는 데 필수적이다.
2) 오픈소스 및 상용 검증 도구를 이용한 분석 및 결과 비교를 통해 취약점 개선 사항 식별 및 성능을 비교, 이는 다양한 도구의 장점을 활용하여 보다 효과적인 검증을 가능하게 한다.
II. RUST기반 암호모듈의 최소 안전성 확보를 위한 검증규칙 제안
RUST 언어는 메모리 안전성과 코드 품질이 중요한 보안 시스템 및 네트워크 암호모듈 개발에 적합하며, RUST는 보안 중심의 최신 시스템에 유리한 개발 언어이다. 따라서 RUST 기반의 암호모듈 구현 시 이러한 특징을 고려한 검토(검증/분석)가 필요하다.
Fig. 1. RUST vs. other programming language features
본 연구에서는 우선 프랑스 ANSSI의 'Programming Rules to Develop Secure Applications with Rust' 가이드라인(개발환경, 라이브러리, 언어 일반, 메모리 관리, 타입시스템, Foreign Function Interface의 6개 부분에서 총 51개 규칙과 권고 제시)을 참고하고 분석하여 Fig 2.와 같은 단계를 거쳐 안전한 RUST 프로그램 개발을 위한 일반 규칙으로 6개 부분 총 52개 규칙으로 구성된 규칙을 시험기관과 개발업체에서 참고 가능한 "RUST 기반 소프트웨어 암호모듈 구현 및 검증 시 고려사항"을 제안하고, 이 중에서 RUST 기반 암호모듈 구현에 있어 최소한의 안전성을 확보하기 위한 11개 검증 규칙을 제안한다[1][2].
Fig. 2. Considerations for implementing and Validating RUST-based SW Cryptographic module
2.1 필수 점검 요구사항 제안
본 연구에서는 KCMVP 요구사항을 만족시키면서 RUST 언어 기반의 암호모듈을 안전하게 구현하기 위해 고려해야 할 4개 분야 11개 규칙을 최소 요구사항으로 제안하고, 다음과 같은 주요 점검사항을 포함하고 있다.
- 오래된 의존성 형상 확인: Cargo-outdated 도구 사용[9]
- 보안 취약점 확인: Cargo-audit, Trivy 등을 사용한 의존성 취약점 점검[3][5]
- 메모리 관리 안전성: unsafe 블록 사용 제한 및 메모리 누수 방지[1]
- 소스코드 취약점 분석: 정적 분석 도구를 활용한 소스코드에서 panic 및 forget 함수 등 안전하지 않은 함수 사용 금지[1]
제안한 11개 검증규칙은 다음 Table 1과 같다.
Table 1. Mandatory checks(11 types)
RUST 기반 암호모듈에서 메모리 안전성, 외부 의존성 관리, 동시성 안전성, 성능 최적화, 규제 준수 등의 이유로 보안 요구사항 검토가 필수적이다. 따라서 위 각 항목은 KCMVP 암호모듈 구현 요구사항(검증필 암호모듈 운용 가이드, 구현 안내서, 제출물 작성안내서 등)을 기반으로 최신 개발언어 기반 암호모듈에 해당하는 항목을 선정하였다.
2.2 필수 점검 요구사항 점검 내용
RUST 기반 암호모듈 구현 시 보안 및 성능요구사항을 충족하기 위해 2.1 항 Table 1에서 제시된 점검 요구사항 항목을 필수적으로 검토해야 한다. 암호모듈의 특성상 보안 및 신뢰성검증이 핵심 요소이다. RUST 기반 암호모듈 구현에서는 성능 최적화와 보안 요구사항 충족이 필수적이다. 이를 위해 메모리 안정성, 의존성 검증, 성능 최적화, 동시성 처리 및 규제 준수 등 핵심 요소를 검토할 수 있는 기준을 제공한다. 이러한 점검 항목을 검토함으로써 암호모듈의 신뢰성 및 확장성을 강화하고, 실무 적용 가능성을 높일 수 있다. 다음은 일반적인 RUST언어를 이용하여 암호모듈을 개발하는경우 점검해야 하는 검증규칙 11종의 점검 방법이다.
2.2.1 오래된 crates 의존성 점검
- “Cargo-outdated” 도구를 사용하여 취약점이 발생할 수 있는 오래된 의존성을 점검하고 제거해야 한다.
- 위 예시와 같이 검출된 의존성 정보(버전 정보 등)를 확인하고 오래된 의존성에 대해서는 업데이트를 수행하거나 특정 버전을 선택한 정당한 이유를 설명할 수 있어야 한다.
Fig. 3. Cargo-outdated example in RUST
2.2.2 crates 의존성에서 보안 취약점 확인
- “Cargo-audit 및 Trivy”를 사용하여 외부 crate의 잠재적인 보안 취약점을 점검한다.
- 예시와 같이 외부 crate의 의존성 취약점이 검출되는 경우(time crate의 버전 업그레이드 필요) 결과를 확인하고 해당하는 취약점에 대해서 조치를 취해야 한다.
Fig. 4. Cargo-audit example in RUST
2.2.3 crates 라이선스 검토
- “Cargo-deny” 도구를 사용하여 외부 crate 사용 시 라이선스 충돌 여부를 검토하고 관리되어야 한다.
- RUST 언어의 개발 역사가 짧아서 암호 라이브러리에서 외부 crate를 사용하는 경우가 많다. 암호 라이브러리의 경우, 개발업체가 책임이 있으므로 외부 crate에 대해서도 라이선스 조건을 만족시켜야 하며, 외부 crate의 소스코드 제출 취약점 보완 등이 가능해야 한다.
2.2.4 소프트웨어 구성 정보 확인
- 소프트웨어 구성 정보를 관리하고, 신뢰할 수 있는 crate만 사용해서 암호모듈을 구현해야 한다.
- 관련 정보를 확인하기 위해 cargo-supply-chain도구를 사용해서 소프트웨어 구성 정보를 확인하고 관리해야 한다.
2.2.5 메모리 관리 안정성(Unsafe keyword)
- “unsafe” 키워드 사용을 지양하고, 필요시 Table 1에서 요구하는 요구사항을 만족하기 위해 안전성에 해를 끼치지 않는다는 정당성을 입증해야 한다.
※ RUST는 저수준의 시스템 프로그래밍(예: 운영체제와 직접 상호작용 등) 작업을 지원하기 위해 unsafe 키워드를 통한 안전하지 않은 코드 사용을 허용하고 있다.
- Rust의 Foreign Function Interface(FFI)는 extern "C" 접두사를 사용하여 C로 작성된 함수의 구현을 설명할 수 있다. 이러한 함수를 사용하려면 unsafe 키워드가 필요하다. 안전하고 원활하게 C 코드를 호출하기 위해 아래 예시와 같이 "Safe" wrapper가 정의되어야 한다.
- 임베디드 장치의 경우 레지스터와 다양한 기타 리소스는 종종 고정된 메모리 주소를 통해 접근된다. 이 경우 Rust에서 해당 포인터를 초기화하고 역참조하려면 unsafe 블록이 필요하다. 코드에서 unsafe 액세스의 수를 최소화하고 프로그래머가 쉽게 식별할 수 있도록 해야한다.
extern "C" {
fn add(a: i32, b: i32) -> i32;
}
fn safe_add(a: i32, b: i32) -> i32 {
let result = unsafe {
add(a, b)
};
result
}
fn main() {
let result = safe_add(1, 2);
println!("The sum is {}", result);
}
struct Register {
address: *mut u32,
value: u32,
}
impl Register {
fn read(&self) -> u32 {
unsafe {
*self.address
}
}
fn write(&self, value: u32) {
unsafe {
*self.address = value;
}
}
}
fn main() {
let mut register = Register {
address: 0x12345678 as *mut u32, value: 0,
};
let value = register.read();
println!("The value of the register is {}", value);
register.write(123);
let value = register.read();
println!("The value of the register is {}", value);
}
2.2.6 Panic 함수 사용 제한
- “panic!" 매크로 사용을 제한하고, 오류 처리는 Result 타입을 통해 명시적으로 처리해야 한다.
- 런타임 시 패닉을 유발할 수 있는 함수 또는 명령을 사용하지 않아야 한다.
- 명시적 오류 처리(Result)는 ”panic!" 매크로를 호출하는 대신 항상 선호되어야 한다. 오류의 원인이 제공되어야 하며, 일반 오류는 피해야 한다.
- 패닉을 일으킬 수 있는 일반적인 패턴은 다음과 같으며, 이를 지양해야 한다.
• unwrap 또는 expect 사용,
• assert 사용,
• 배열에 대한 검사되지 않은 액세스,
• 디버그 모드에서 정수 오버플로,
• 0으로 나누기,
• 대규모 할당,
• format!을 사용하여 문자열 형식 지정
2.2.7 Forget (std::mem) 함수 사용 제한
- “std::mem::forget” 함수의 사용을 제한하고, 리소스 해제가 적절히 이루어지는지 확인해야 한다.
※ RUST에서 “std::mem::forget“을 사용할 경우 해당 값이 관리하는 리소스에 대한 접근은 불가능한 상태가 되지만, 해당 리소스와 관련된 소멸자는 실행되지 않는다. 따라서 잘못 사용될 경우 데드락이 발생하거나 메모리에서 민감한 정보가 삭제되지 않을 수 있음을 주의해야 한다.
- Rust의 linter인 Clippy의 mem_forget을 사용하여 ”std::mem::forget“ 함수의 사용을 자동으로 감지할 수 있다. crate에서 forget의 사용을 금지하려면 루트 파일(보통 src/lib.rs 또는 src/main.rs)의 맨 위에 다음을 추가하는 방식으로 해결 가능하다.
#![deny(clippy::mem_forget)]
2.2.8 Box::leak 사용 시 메모리 해제 관리
- “Box::leak” 사용 후 반드시 메모리 해제 여부를 확인해야 한다.
- 위 예시는 Unsafe, forget, uninitialized,Box::leak 가 사용된 예시로 위에서 설명한 바와 같이 취약점이 발생하지 않도록 조치를 취해야 한다.
Fig. 5. Unsafe, forget, uninitialized, Box::leak example in RUST
2.2.9 ManuallyDrop 사용 관리
- 적절한 시점에 Table 2와 같은 예시와 같이 수동 또는 자동으로 메모리 해제를 수행해야 한다.
Table 2. Example of ManuallyDrop::into_inner
※ 컴파일러가 자동으로 소멸자를 호출하는 것을 방지하는 Wrapper로서 Box::leak과 마찬가지로 적절한 시점(더 이상 사용되지 않는 경우)에 메모리를 해제하는지 확인이 필요하다. 이는 ManuallyDrop과 Box::into_raw은 해제 책임이 개발자에게 있음을 의미한다.
- 안전한 Rust 개발을 위해 Table 3과 같이 ManuallyDrop으로 감싸진(wrapped) 모든 값이 자동 해제(ManuallyDrop::into_inner)되거나 수동 해제(unsafe ManuallyDrop::drop)되도록 unwrapped 되어야 한다.
Table 3. Example of unsafe ManuallyDrop::drop
2.2.10 초기화되지 않은 메모리 사용 금지
- std::mem::uninitialized 및 MaybeUninit의 사용을 피하고, 초기화되지 않은 메모리가 발생하지 않도록 관리해야 한다.
- 위 두 가지 구현 방법을 사용하여 초기화되지 않은 메모리가 사용되는 경우, 초기화되지 않은 메모리에 대한 drop 또는 초기화된 메모리에 대한 drop 누락 이슈가 발생 가능하다.
- 초기화되지 않은 메모리는 다음 2가지 보안 문제가 발생할 수 있다.
• 초기화되지 않은 메모리의 drop: 초기화되지 않은 값이 drop 되면 잘못된 메모리 주소에 접근하여 Undefined Behavior가 발생 가능하다. 초기화되지 않았으므로 임의의 값이 메모리에 존재하여 이 값을 읽을 수 있다. 또는 임의의 값을 쓰는 것도 가능하다.
• 초기화된 메모리의 non-drop: MaybeUninit을 사용하면 자동으로 drop 되지 않은다. 따라서 초기화하면 직접 drop 되도록 해야 한다. 따라서 암복호화키 등 민감한 정보가 drop 되지 않을 수 있다.
2.2.11 Drop trait 구현 시 주의
- “Drop” 절차가 누락 되지 않도록 주의해야 한다.
※ Drop이 누락 될 수 있는 예시: forget, panic, program aborts, reference cycle
- 보안성 보장을 위해 Drop에만 의존을 금지해야 한다.
• 예를 들어 어떤 동작의 끝에서(예: 암호화 작업의 마지막에서 키 삭제) 보안작업을 보장하기 위해서는 Drop trait의 구현에만 의존해서는 안 된다.
• 암호화 키를 삭제하는 drop 함수는 키가 삭제되었는지 확인하기 위해 추가 검사를 수행해야 한다.
III. 취약성 점검 수행
본 연구에서는 RUST 기반 암호모듈의 검증을 위해 다양한 정적 및 동적 분석 도구를 활용하였다. 이 과정에서 오픈소스 도구(Cargo Audit, Clippy, Miri, MIRAI 등)를 사용하여 분석을 수행하였으며, 분석 결과의 신뢰성 확보를 위해 상용도구인 CodeSonar를 사용하여 분석을 수행하여 분석 결과를 비교하고 보완이 필요한 항목과 성능을 비교 분석하였다.
3.1 분석 도구
1) Cargo Audit 및 Cargo Supply Chain: 의존성 보안 취약점 분석
2) Clippy: 코드 리뷰 및 품질 개선
3) MIRAI: 정적 분석으로 메모리 안전성 위반 탐지
4) Miri: 런타임 검사로 초기화도지 않은 자원 사용 점검
5) CodeSonar: 상용 도구로 종합적 비교 기준 제공
3.2 분석 대상 암호 라이브러리
대상 암호 라이브러리는 Table 4와 같이 “RustTLS” 등 4종으로 RUST 언어 기반으로 공개된 암호 기능을 제공하는 라이브러리이며, 이를 대상으로 "RUST 기반 소프트웨어 암호모듈 구현 및 검증 시 고려사항" 문서를 기반으로 검토하여 안내서 문서의 실효성에 대해 다음과 같은 암호 라이브러리를 대상으로 분석 및 검토하였다[11][12][13][14].
Table 4. Test target Library
3.3 오픈소스 도구 분석 결과
본 연구에서는 다양한 오픈소스 도구를 활용하여 RUST 기반의 암호 라이브러리 소스코드의 보안검증과 코드 품질 검사를 수행하도록 실험용 스크립트를 구성하였으며, 스크립트의 주요 특징과 기능은 다음과 같다.
1) 구성 및 환경 설정
- 시험 환경 설정, 결과 저장 디렉터리 생성, 도구 목록 정의 및 초기화 설정 포함
- 자동화된 도구 실행을 위해 Shell Script기반의 프로세스 구성
2) 검사 도구 목록 및 주요 기능
- 정적 분석 도구: clippy, cargo-audit, cargo-deny 등을 이용하여 코드 품질 및 의존성 검증
- 동적 분석 도구: Miri, MIRAI 등을 활용하여 메모리 관리 및 실행 중 오류 탐지
- 보안 분석 도구: trivy, cargo-supplychain을 이용하여 취약점 및 공급망 보안 검사
3) 안전성 검증 기능
- 'unsafe' 키워드 및 위험 코드 검출 기능을 포함하여 보안 취약점 검출 강화
해당 도구들은 2.1항에서 제시한 필수 점검 요구사항의 점검 항목을 모두 포함해서 점검을 수행하는 도구들로 구성되어 있다. 해당 도구를 활용한 분석 결과는 다음 Table 5와 같다.
Table 5. Result of 4 libraries
※ The above detection results may vary depending on the tool’ option settings, so the detected results may not be identical.
분석에 사용된 주요 도구들과 이들이 2.1항의 필수 점검 요구사항(Table 1) 중 어떤 항목들을 검증하는지는 다음과 같다.
1) 의존성 관리 (요구사항 1, 2, 3, 4)
- cargo-outdated: 오래된 의존성 버전 점검 (요구사항 1)
- cargo-audit, Trivy: 의존성의 알려진 보안 취약점 점검 (요구사항 2)
- cargo-deny: 의존성 라이선스 호환성 검토(요구사항 3)
- cargo-supply-chain: 소프트웨어 구성 요소(SBOM) 및 출처 신뢰성 확인(요구사항 4)
2) 언어 일반 및 메모리 관리 (요구사항 5, 6, 7, 8, 9, 10)
- Clippy: unsafe 블록 사용(요구사항 5), panic! 유발 가능 함수(요구사항 6), forget 함수 사용(요구사항 7), ManuallyDrop 관리(요구사항 9), 초기화되지 않은 메모리 사용 패턴(요구사항 10) 등 다양한 코드 품질 및 잠재적 오류 패턴 탐지
- MIRAI: 정적 분석을 통해 unsafe 코드 관련 문제(요구사항 5), 메모리 누수 가능성(요구사항 8), 잘못된 Drop 구현(요구사항 11) 등 메모리 안전성 위반 가능성 탐지
- Miri: 동적 분석(런타임 인터프리터)을 통해 초기화되지 않은 메모리 사용(요구사항 10), unsafe 코드의 정의되지 않은 동작(UB), 메모리 누수(요구사항 8) 등 실제 실행 시 발생 가능한 오류 검증
※ Table 5의 예시에서 MIRAI 경고 건수가 매우 많았던 이유는 정적 분석의 특성상 코드 경로와 메모리 관련 동작을 보수적으로 분석하기 때문이며, 이로 인해 false positive가 다수 발생할 수 있다. 반면 Miri는 특정 입력과 실행 흐름에 따라 메모리 오류를 런타임에 실제 발생시점에 탐지하므로 분석 결과가 상대적으로 적다. 이 둘은 상호보완적으로 활용되어야 한다.
3) 수동 검토: unsafe 키워드 개수 확인 및 사용 적절성 검토 (요구사항 5)
4) 타입 시스템 (요구사항 11)
- Clippy, MIRAI, Miri: Drop 트레잇 구현 시 누락될 수 있는 절차(예: 리소스 해제 누락)나 잘못된 구현으로 인한 잠재적 문제 탐지
4개 암호 라이브러리(AWS Libcrypto for Rust, Rust-Crypto, Rustls, Ring)를 대상으로 위 도구들을 적용하여 분석한 결과는 Table 5와 같다. 이 결과는 각 도구가 탐지한 이슈의 수를 나타내며, 이를 2.1항의 요구사항 관점에서 해석하면 다음과 같다.
1) 요구사항 1 (오래된 의존성): cargo-outdated실행 결과, AWS Libcrypto for Rust에서18개, 나머지 라이브러리에서 각 1개의 오래된 의존성이 발견되었다. 이는 최신 버전으로 업데이트하거나 사용 이유에 대한 명확한 소명이 필요함을 시사한다.
2) 요구사항 2 (의존성 취약점): cargo-audit는 AWS Libcrypto, Rust-Crypto, Rustls에서 각각 1, 1, 3개의 의존성 관련 보안 권고(vulnerability advisory)를 탐지했다. Trivy는 위험 수준별로 더 많은 잠재적 이슈(각각 10, 3, 5, 1개)를 식별하여 교차 검증의 중요성을 보여준다.
3) 요구사항 3 (라이선스): cargo-deny는 모든 라이브러리에서 다수의 라이선스 관련 이슈(7~15개)를 발견하여, 라이선스 정책 준수 여부 검토가 필요함을 나타낸다.
4) 요구사항 4 (SBOM): cargo-supply-chain은 각 라이브러리가 의존하는 crate의 수(3~20개)와 그 출처 정보를 제공하여, 공급망 보안 검토의 기초 자료를 제공한다.
5) 요구사항 5 (unsafe 사용): unsafe 키워드는 모든 라이브러리에서 발견되었으며(50~160회), 특히 AWS Libcrypto와 Rust-Crypto에서 빈도가 높았다. 이는 FFI 사용 등 불가피한 경우일 수 있으나, 각 사용처의 안전성 검토 및 문서화가 필수적임을 의미한다. MIRAI가 탐지한 다수의 경고 중 상당수는 unsafe 블록과 관련된 잠재적 문제를 포함할 수 있다.
6) 요구사항 6, 7, 9 (Panic, Forget, ManuallyDrop): Clippy(Table 5에는 결과가 직접 없으나 분석 도구 목록에 포함)는 이러한 함수/패턴 사용을 탐지할 수 있다. MIRAI의 경고에도 관련 내용이 포함될 수 있다.
7) 요구사항 8, 10, 11 (메모리 누수, 초기화, Drop): Miri는 런타임 검사 결과 4개 라이브러리 모두에서 초기화되지 않은 메모리 사용 등 명백한 오류는 탐지하지 못했다(0건). 그러나 이는 특정 실행 경로에 대한 결과이며, 잠재적 누수나 Drop 관련 문제는 MIRAI의 정적 분석 결과(다수 경고)에서 추가적인 검토가 필요함을 시사한다.
분석 결과, 단일 도구만으로는 모든 요구사항을 충분히 검증하기 어렵다는 점을 확인했다. 예를 들어, 의존성 취약점 점검 시 cargo-audit와 Trivy를 함께 사용하고, 메모리 관련 문제는 정적 분석(MIRAI, Clippy)과 동적 분석(Miri)을 병행하며, unsafe 사용은 도구 탐지 외에도 수동 검토가 필수적이다. 따라서 본 논문에서 제시한 오픈소스 도구 조합은 11개 필수 점검 요구사항에 대한 커버리지를 높여, 검증 누락을 최소화하고 분석의 신뢰성을 향상시키는 효과적인 접근 방식임을 알 수 있다.
3.4 상용 정적 분석 도구 분석 결과
오픈소스 도구 분석 결과와의 교차 검증 및 심층 분석을 위해, RUST 언어를 지원하는 상용 정적 분석 도구인 CodeSonar를 사용하여 4종의 암호 라이브러리를 대상으로 추가 분석을 수행하였다. CodeSonar는 다양한 규칙셋(CWE, CERT 등)을 기반으로 소스코드의 잠재적 결함과 취약점을 탐지한다. CodeSonar는 MIRAI와 달리 사용자 주석 부재나 코드 복잡도 등 문서화 및 유지보수 관점까지 포함한 정밀 진단이 가능하며, 이는 Clippy, cargo-audit 등의 오픈소스 도구가 놓칠 수 있는 정성적 결함 탐지에 효과적이다. 특히, MissingSafety Doc, Identity Op 등은 코드 안전성과 품질 확보에 있어 중요한 시사점을 제공한다.
CodeSonar의 분석 결과(Table 6은 RustTLS에 대한 결과 요약 예시)를 2.1항의 11개 필수 점검 요구사항 관점에서 재분류하고 해석하면 다음 Table 6과 같다.
Table 6. Example of Codesoanr analysis results(rustls-main)
1) 의존성 관리 (요구사항 1, 2 관련):
- CodeSonar는 'Legacy Numeric Constants'와 같은 경고를 통해 오래되었거나 권장되지 않는 코딩 스타일을 탐지할 수 있으며, 이는 요구사항1(오래된 의존성)과 간접적으로 연관될 수 있다. 직접적인 의존성 버전이나 취약점 데이터베이스 스캔 기능은 오픈소스 도구(cargo-outdated,cargo-audit)가 더 특화되어 있다.
2) 언어 일반 및 메모리 관리(요구사항5, 6, 7,8, 9, 10 관련):
- 요구사항 5 (unsafe 사용): CodeSonar는 'Missing Safety Doc' 경고를 통해 unsafe 함수/블록 사용 시 안전성에 대한 문서화(주석 등)가 누락되었음을 지적한다. 이는 unsafe 사용의 정당성 입증 요구사항과 직접 연결된다. (Table 7: MissingSafety Doc)
Table 7. Comparison of open-source tools and CodeSonar analysis results
- 요구사항 6 (Panic): 'Suspicious Arithmetic Impl' 등 예상치 못한 동작(패닉 포함)을 유발할 수 있는 산술 연산 관련 경고를 탐지할 수 있다. (Table 7: Suspicious Arithmetic Impl)
- 요구사항 7, 8, 9 (Forget, Leak, ManuallyDrop): CodeSonar의 정밀한 데이터 흐름 및 포인터 분석은 리소스 누수나 부적절한 해제와 관련된 잠재적 결함을 탐지하는 데 도움을 줄 수 있다. (Table 7의 Memory Safety 항목과 연관)
- 요구사항 10 (Uninitialized): 'Uninit Vec'과 같은 경고를 통해 초기화되지 않은 변수나 메모리 사용 가능성을 직접적으로 지적한다. (Table 7: Uninit Vec)
3) 코드 품질 및 문서화 (요구사항 5, 11 및 일반적 품질 관련):
- 'Dead Code' 경고는 사용되지 않는 코드를 식별하여 제거를 권장하며, 이는 코드 간 결성 및 유지보수성과 관련된다. (Table 7: Dead Code)
- 'Identity Op', 'Needless Borrow', 'Needless Pass By Value' 등은 불필요하거나 비효율적인 코드를 지적하여 최적화 및 가독성 향상을 유도한다. (Table 7: Code Complexity and Optimization)
- 'Missing Errors Docs', 'Doc Markdown' 등 다수의 문서화 관련 경고는 코드의 이해도 및 유지보수성, 특히 오류 처리 및 unsafe 사용의 명확성(요구사항 5, 6 관련)을 강조한다.
RustTLS 분석 예시(Table 6)를 보면, 문서화 관련 경고('Doc Markdown', 'Missing Errors Docs')가 가장 많았고, 불필요한 코드 패턴('Must Use Candidate', 'Needless Pass By Value' 등)과 관련된 경고도 다수 발견되었다. 이는 CodeSonar가 코드의 상세한 구현 패턴과 문서화 수준까지 깊이 있게 분석함을 보여준다.
결론적으로, CodeSonar는 11개 필수 점검 요구사항 중 특히 메모리 안전성(요구사항 5, 7, 8, 9, 10), unsafe 사용의 문서화(요구사항 5), 초기화 문제(요구사항 10), 잠재적 패닉 유발 코드(요구사항 6) 등 코드 레벨의 정밀한 분석에 강점을 보인다. 또한 코드 최적화 및 문서화 같은 전반적인 코드 품질 측면에서도 상세한 피드백을 제공한다. 이는 오픈소스 도구들이 강점을 보이는 의존성 관리(요구사항1, 2, 3, 4)와 상호 보완적인 역할을 할 수 있음을 시사한다.
3.5 분석 결과 비교 및 평가
본 연구에서는 RUST 기반 암호모듈의 코드 품질과 보안성을 2.1항에서 제안한 11개 필수 점검 요구사항 관점에서 검증하기 위해, 3.3항의 오픈소스 도구 조합과 3.4항의 상용 정적 분석 도구(CodeSonar)를 활용한 분석 결과를 비교 및 평가하였다. 이 평가는 각 접근 방식이 11개 요구사항을 얼마나 효과적으로 점검하고, 어떤 강점과 한계를 가지는지 분석하는 데 중점을 둔다. 그 결과는 다음 Table 7과 같다.
3.5.1 필수 점검 요구사항별 커버리지 비교
1) 의존성 관리 (요구사항 1~4):
- 오픈소스 도구: cargo-outdated(요구사항 1), cargo-audit/Trivy(요구사항 2), cargo-deny(요구사항 3), cargo-supplychain(요구사항 4) 등 각 요구사항에 특화된 도구들을 통해 직접적이고 포괄적인 검증이 가능했다. Table 5의 결과는 실제 라이브러리들에서 오래된 의존성, 보안 취약점, 라이선스 이슈 등이 다수 존재함을 명확히 보여주었다.
- CodeSonar: 이 영역에 대한 직접적인 기능은 부족하다. 'Legacy Numeric Constants' 탐지 등 간접적인 연관성은 있으나, 의존성 데이터베이스 연동이나 라이선스 검증 기능은 제공하지 않아 요구사항 1~4의 검증에는 오픈소스 도구가 필수적이다.
- 평가: 의존성 관리 측면에서는 오픈소스 도구 조합이 명백한 강점을 가지며, 필수 요구사항 1~4를 충족하기 위한 핵심적인 역할을 수행한다.
2) 언어 일반 및 메모리 관리 (요구사항 5~10):
- 오픈소스 도구:
• unsafe 사용(요구사항 5) 빈도 확인 및 Clippy, MIRAI를 통한 정적 분석, Miri를 통한 동적 분석으로 관련 오류 탐지가 가능하다. 단, unsafe 사용의 정당성 자체는 수동 검토가 필요하다.
• panic! 유발 코드(요구사항 6), forget(요구사항 7), Box::leak(요구사항 8)
• ManuallyDrop(요구사항 9) 관련 패턴은 Clippy가, 그로 인한 메모리 문제는 MIRAI/Miri가 탐지할 수 있다.
• 초기화되지 않은 메모리 사용(요구사항 10)은 Miri의 핵심 검증 영역이며, Clippy와 MIRAI도 관련 분석을 지원한다.
- CodeSonar:
• 'Missing Safety Doc'(요구사항 5)경고는 unsafe 사용의 문서화 및 정당성 검토 필요성을 직접적으로 제기한다. 정밀한 분석은 unsafe 관련 미묘한 버그 탐지에 강점을 보인다.
• 'Suspicious Arithmetic Impl'(요구사항 6), 'Uninit Vec'(요구사항 10)등 특정 경고를 통해 패닉 유발 가능성이나 초기화 문제를직접지적한다.
• 강력한 데이터 흐름 및 포인터 분석은 요구사항 7, 8, 9와 관련된 리소스 누수나 부적절한 해제 등 복잡한 메모리 안전성 문제 탐지에 효과적이다.
- 평가: 요구사항 5~10에 대해서는 두 접근 방식 모두 중요한 역할을 수행하며 상호 보완적이다. 오픈소스 도구는 다양한 분석 방식(linting, static, dynamic)을 제공하며 특히 Miri를 통한 런타임 검증은 고유한 강점이다. CodeSonar는 깊이 있는 정적 분석과 unsafe 관련 문서화 강조 등에서 강점을 보인다. 따라서 이 영역의 요구사항을 완전히 충족하려면 두 접근법을 병행하는 것이 이상적이다.
3) 타입 시스템 및 Drop 구현(요구사항 11):
- 오픈소스 도구: MIRAI의 정적 분석과 Miri의 동적 분석은 잘못된 Drop 구현으로 인한 리소스 누수나 정의되지 않은 동작을 탐지할 수 있다. Clippy도 관련 패턴을 식별할 수 있다.
- CodeSonar: 정적 분석을 통해 Drop 구현과 관련된 잠재적 상태 오류나 리소스 관리 문제를 탐지할 수 있다.
- 평가: 요구사항 11 역시 두 접근 방식 모두 기여하며, 특히 실행 시점에서 문제를 드러내는 Miri와 정적 분석 기반의 MIRAI/CodeSonar가 상호 보완적으로 작용한다.
3.5.2 종합 평가 및 전략 제안
두 접근 방식(오픈소스 도구 조합, 상용 CodeSonar) 모두 분석 대상 라이브러리에서 코드 최적화, 메모리 관리 개선, 보안 강화의 필요성을 성공적으로 식별했으며, 이는 본 연구에서 제안한 11개 필수 점검 요구사항 기반의 검증이 유효하고 중요함을 뒷받침한다.
비교 결과, 오픈소스 도구 조합은 비용 효율성이 높고, 특히 의존성 관리(요구사항 1~4) 영역에서 필수적인 역할을 하며, Clippy를 통한 광범위한 코드 품질 검사 및 Miri를 통한 동적/런타임 검증에서 강점을 보였다. 반면, 상용 도구 CodeSonar는 정밀한 정적 분석을 통해 복잡한 메모리 안전성 이슈(요구사항 5, 7, 8, 9, 10, 11) 탐지와 unsafe 코드 및 문서화 검증(요구사항 5)에서 상대적으로 우위를 가지며, 보다 심층적인 분석 결과를 제공했다.
따라서 RUST 기반 암호모듈의 안전성을 효과적으로 검증하기 위한 최적의 전략은 다음과 같이 제안 될 수 있다:
1) 기본 검증: 오픈소스 도구 조합(Cargo Audit, Clippy, Miri, MIRAI 등)을 활용하여 11개 요구사항 전반에 대한 광범위하고 비용 효율적인 자동 검증 프로세스를 구축한다. 특히 의존성 관리(요구사항 1~4)는 오픈소스 도구를 통해 반드시 수행한다.
2) 심층 검증 (보완): 상용 정적 분석 도구(CodeSonar 등)를 보완적으로 활용하여, 오픈소스 도구만으로 탐지가 어렵거나 더 높은 수준의 보증이 필요한 영역(예: 복잡한 unsafe 블록, 미묘한 메모리 누수, 중요 함수의 Drop 구현 등 요구사항 5~11 관련)에 대한 정밀 분석을 수행한다.
이러한 상호 보완적인 검증 프로세스를 통해, 11개 필수 점검 요구사항을 효과적으로 만족시키고 RUST 기반 암호모듈의 검증 자동화와 신뢰성 강화를 동시에 달성할 수 있다. 이는 결과적으로 KCMVP 등 보안 인증 요구사항 충족에도 기여할 것이다.
IV. 결론
본 연구에서는 RUST 언어의 메모리 안전성 및 오류 방지 기능을 활용하여 구현된 암호 라이브러리를 대상으로 최소한의 안전성을 확보하기 위한 규칙을 제시하였다. RUST 언어 기반구현물에 대한 11개 필수 점검 규칙을 적용하여 오프소스 도구를 활용한 점검 결과를 제시하고, 상용도구를 활용하여 분석 결과에 대한 신뢰성을 비교 분석하였다. 이를 통해 RUST 기반 암호모듈의 신뢰성과 보안성을 강화하고 최소한의 안전성을 확보 가능한 오픈소스 도구 기반 검증 프로세스의 실무 적용 가능성을 입증하였다.
향후 연구에서는 다중 도구 조합 검증의 신뢰성을 한층 강화할 계획이다. 또한, 실제 배포 환경에서의 부하 테스트와 실시간 처리 성능 평가를 통해 메모리 안전성과 처리 속도의 조화를 이루는 최적의 구현 방안을 제시할 것이다. 이러한 연구 결과는 RUST 언어 기반 암호 모듈 검증을 보다 체계화하고 다양한 보안요구사항에 적합한 구현 사례를 제공함으로써 실무 활용도를 높일 수 있을 것으로 기대된다.
References
- Steve Klabnik, Carol Nichols, and Chris Krycho, "The RUST Programming Language", https://doc.rust-lang.org/book, 17 Feb. 2025
- ANSSI, "Programming Rules toDevelop Secure Applications withRust", ANSSI-PA-074-EN, 06 September 2020
- Cargo Audit, "Cargo Audit" https://docs.rs/cargo-audit/latest/cargo_audit, May 2025
- Cargo Deny, "Cargo Deny" https://github.com/EmbarkStudios/cargo-deny, May 2025
- Trivy, "Trivy" https://trivy.dev/, May 2025
- MIRAI, "MIRAI" https://github.com/facebookexperimental/MIRAI, May 2025
- Miri, "Miri" https://github.com/rustlang/miri, May 2025
- cargo-supply-chain, "cargo-supply-chain" https://github.com/rust-secure-code/cargo-supply-chain, May. 2025
- cargo-outdated, "cargo-outdated" https://github.com/kbknapp/cargo-outdated, May 2025
- Clippy, "Clippy" https://github.com/rust-lang/rust-clippy, May 2025
- aws-lc-rs, "AWS Libcrypto for Rust" https://github.com/aws/aws-lc-rs, May 2025
- Rust-Crypto, "Rust-Crypto" https://github.com/DaGenix/rust-crypto/tree/master, May. 2025
- RUSTLS, "RUSTLS" https://github.com/rustls/rustls, May 2025
- Ring, "Ring" https://github.com/brainsmith/ring/security/policy, May 2025