안녕하세요. 저희는 팀 퀀트(Quant)이며, 저는 Quant Theodore Felix라고 합니다.
이 프로젝트에 기여해주시는 모든 여러분에게 정말 감사드리며, 몇 가지 사전 준비 사항을 알려드리고자 합니다. 우선, 이 프로젝트는 MIT LICENSE를 따르지만 상위 프로젝트인 "얽힘 라이브러리"는 PolyForm Noncommercial License 1.0.0 라이선스를 따르기 때문에 상업(경제)적 선에서 자유롭지 못한 것을 이해해주시길 바랍니다. 정리하면 다음의 용도가 가능합니다.
- 허용: 학습, 개인 프로젝트, 비영리 연구, 교육 목적의 내부적 사용 등.
- 금지: 직접적 판매 행위, 상용 서비스 내부 활용, 영리 회사 내 업무 사용 등.
저희 팀은 모든 프로젝트를 진행함에 있어 매우 엄격한 보안과 효율적인 메모리 관리를 중요시합니다. 여러분은 이 프로젝트의 보안 정책을 참고하실 수 있습니다.
이 프로젝트에 기여하기 전, 얽힘 라이브러리의 보안 철학에 따라 "내가 작성한 코드는 보안에 충실한가?" 라는 의문을 가져주시길 바랍니다!
여러분이 쉽고 빠르게 코드를 작성하고, 여러분의 변경을 적극적으로 반영하기 위해 다음의 기본 규칙을 정의했습니다. 해당 규칙은 메인테이너와 기여자 여러분 모두에게 공통적으로 적용됩니다.
- 여러분은 Rust, C/C++ 기반의 코드를 작성하실 수 있습니다. 이 떄 명심해야 하는 것은, FFI 경계 통신 표준을 위한 구현입니다. 말인 즉슨, 작성되는 코드가 외부로부터 접근 가능한 부분과 핵심 연산이 수행되는 부분이 엄격히 차별(캡슐화)되어 있어야 합니다.
- 기본적으로 저희는 적극적인 테스트를 예상합니다. 이는 간단히, 여러분이 작성한 기능에 대해 명확한 테스트가 존재해야 함을 의미합니다. 테스트는 프로젝트 발전 뿐 아니라 여러분이 작성한 코드를 파악하는 데 아주 큰 도움이 됩니다. 작성한 기능이 어떻게 동작해야 하고, 특수한 경우에는 어떻게 동작하는지(엣지케이스)에 대해 명확히 테스트를 작성해 주시길 바랍니다. 테스트에서도 아주 치명적인 취약점을 발견할 수도 있습니다!
- 그리고 벤치마킹에 관해 알려드리고 싶습니다. 이 프로젝트는
Criterion크레이트를 사용하여 벤치마킹을 진행하고, 그 결과를 benchmarks/ 하위에 명명백백히 기록합니다.entlib-native의 벤치마킹은 "보안성(security)", "처리량(throughout)"의 성능 평가로 구분됩니다. (이 사항은 필수가 아닙니다!)
여러분은 위 규칙에 전적으로 해당되는 아주 방대한 양의 특수 보안 기능에 대한 코드를 작성하실 수 있고, 단순 최적화나 버그, docstring 및 문서 오타 발견 등의 문제를 발견하여 이를 수정하고자 하실 수도 있습니다. 간단한 변경이라 판단되는 경우 위 규칙을 엄격하게 따르실 필요는 없습니다.
좀 더 구체적으로 설명드리자면, 위 규칙은 여러분이 작성한 코드에 외부로부터의 가시성, 함수 및 변수 등의 멤버 정의, 기존 기능의 변경이 포함된 경우에만 적용됩니다. 갑작스러운 오류에 대비하기 위해 저희가 해당 변경을 면밀히 검토하겠습니다.
꽤 특수한 경우로, 만약 여러분이 워크플로를 추가 및 수정(또는 아이디어 논의)하고자 한다면, 반드시 Level 2(후술) 이슈(issues)로 알려주시길 바랍니다. 이는 혼동의 위험이 있기 때문입니다.
상당히 기여 기준점이 높다는 것을 저희도 알고 있습니다. 하지만 이것이 "당신의 코드가 이 규칙을 충족하지 않으면 사용하지 않겠다." 라는 의미가 아님을 명확히 말씀드리고 싶습니다.
저희는 여러분의 피드백이 큰지, 작은지, 중요한지, 필요한지, 의미 있는지 등을 기계처럼 평가하는 단체가 아닙니다. 어디까지나 중요한 것은 여러분 개개인이 가진 철학을 이 코드에 심어주시는 것이며, 단순히 **코드에 대한 감상을 말씀해주시는 것 만으로도 저희는 너무나 감사할 따름입니다! **저희가 말하고 싶은 것은 여러분이 이 코드를 어떠한 방식으로든 리뷰함에 있어 기본적으로 감사함을 느끼고 있다는 것입니다.
짜증나는 규칙으로 인해 이 프로젝트와의 상호 작용을 그만두진 않으셨으면 합니다. 여러분이 이 코드를 리뷰함에 있어 부담감을 느낀다면, 이 프로젝트는 존재 가치가 없다고 저희는 생각하고 있습니다.
저희 팀은 보안의 측면에서 가능한 많은 수에 대비하고, 또 그 행동을 모두와 함께 하는 미래를 그리고 있다는 걸 알아주시면 감사하겠습니다.
위의 규칙은 어쩌면 눈만 아픕니다. 다음의 사항 중 하나에 해당되는 경우, 망설이지 않으셔도 됩니다! 손쉬운 기여를 위해 "레벨"이라는 개념을 사용합니다. 이를 통해 여러분의 기여를 세분화 해보겠습니다.
LEVEL 1- 매우매우 간단함- 마크다운 문서(
.md) 내용에 오류(이상한 문법, 오타, 누락 등)가 있나요? - 필요한 정보(기술 명세 및 기능 사용법 등)가 있나요?
- 필요한 기능에 대한 아이디어를 가지고 계신가요?
- 마크다운 문서(
LEVEL 2- 때에 따라 복합적- 테스트 코드에 문제(잘못된 참조, 특정 상황에 대한 대처가 없음 등)가 있어 보이나요?
- 워크플로(workflow)에 대한 아이디어를 가지고 계신가요? <<= 이 경우 이슈를 통해 남겨주세요!
- 벤치마킹이 잘못 된 것 같거나, 추가적인 벤치마킹 자료가 필요하신가요?
- 기능 캡슐화에 대한 아이디어를 가지고 계신가요?
- 암호학적 연산을 통해 산출된 값에 문제(예상값과 일치하지 않음, 기술 명세에 명시된 연산과 다른 로직 등)가 있어 보이나요?
LEVEL 3- 매우 심각해 보임- NIST의
FIPS,SP또는IG에서 설명된 내용과 다른 로직인 것 같으신가요? - 심각한 보안 취약점을 발견하셨나요? <<= 이 경우 반드시 qtfelix@qu4nt.space로 알려주세요!
- 데이터 소거에 대해, 그 방식 또는 현재 구현된 로직에 대해 의견이 있으신가요?
- 현재 구현된 전반적인 보안 로직의 보안성이 엄밀하지 않다고 판단되시나요?
- NIST의
이 프로젝트에 있어 다음 항목에 해당하는 기여는 Level 3으로 분류되며, 1순위로 검토합니다(물론 보안 기여는 0순위입니다).
- 공통
- 올바른 오류 전파 방법: 많은 크레이트의 핵심 기능은
Result열거형을 통해SecureBuffer구조체와 문자열 참조를 반환합니다. 이는 오류 전파에 부적절합니다. - 컴플라이언스 문제: 암호 모듈 구현에 있어 국제적 인증 및 규정을 준수하지 않은 부분을 발견했다면, 즉시 연락주세요.
- 오류 메시지: 오류 메시지는 기본적으로 모호해야 하지만 알아차리기 애-매한 정도로 진실성이 있어야 합니다. 현재 오류 메시지는 어때 보이시나요?
- 보안 논의:
entlib-native의 보안성에 대해 논의하는 문서에 대해 의견이 있으신가요?
- 올바른 오류 전파 방법: 많은 크레이트의 핵심 기능은
- 보안 버퍼 크레이트
entlib-native-secure-buffer- 베어메탈 캐시 플러시 문제:
zeroizer.rs내 no_std 폐쇄 환경을 위한 Fall-back 시, 해당 환경의 하드웨어(CPU) 특성에 따라 캐시 라인 플러시가 보장되지 않을 수 있다고 합니다. 이 부분에 대해 섬세한 평가검증이 필요합니다. - 이중 잠금: JO(Java-Owned) 패턴을 통해 상호 작용 시 메모리 lock 수행 후 전달됩니다. Rust 측
SecureMemoryBlock구조체는 이 데이터에 대해 한 번 더 lock을 수행합니다. 이 작업에 대해 어떻게 생각하시나요? - 베어메탈 대응: 최신 IoT, HSM, 자동차 천장 시스템(Automotive) 등은 대부분 ARM 기반의 베어메 또는 RTOS 환경에서 구동됩니다. 현재 보안 버퍼는
mlock등의 시스템 콜을 이용해 메모리를 잠그고 있는데, 베어메탈에선 이러한 대응이 불가능합니다. 소프트웨어 레벨에서 '가능한 대응'에 대한 아이디어가 필요합니다.
- 베어메탈 캐시 플러시 문제:
- CI 워크플로
- 엄격한 상수-시간 검사: 현재 구현된 상수-시간 연산이 부족해 보이시거나, 엄격한 검증을 위해서는 어떻게 해야 한다고 생각하시나요?
- 메모리 오염 추적 방법: CC 상수-시간 감사 워크플로의 Level 3(바이너리 메모리 오염 추적)은 Unix 환경에서 Valgrind를 사용하여 테스트를 수행합니다. 하지만 저는 아직 이 부분에 대해 큰 아이디어가 없어 임시 비활성화해둔 상태입니다. 이 부분에 대해 좋은 아이디어를 가지고 있다면 알려주세요.
여러분은 위 내용에 있어 (특정 항목만 제외하고) 어떤 방식으로든 저희에게 연락하실 수 있습니다.
이메일 qtfelix@qu4nt.space 또는 디스코드 qtfelix를 사용하실 수 있습니다.