부록 — 위험함수 치환표·암호화 기준표·PQC 전환
가이드 원문은 2012년 문서다. 58개 항목의 원리와 CWE 분류는 지금도 유효하지만, 권장 알고리즘·키 길이·대체 함수는 여기 정리한 현재 기준을 따른다. 특히 3DES·SHA-1·단순 해시 패스워드 저장은 현재 기준으로는 사용하지 않는다.
1. 위험 함수 → 안전 함수 치환표
★ 가이드 원문 명시 항목. 코드 리뷰·정적분석 금지 목록의 기준표로 그대로 쓴다. → Part 7. API 오용
| 구분 | 위험 함수 | 위험 사유 | 권장 대체 |
|---|---|---|---|
| ★ 표준입력 | gets() | 입력 크기를 점검하지 않음(C11에서 삭제) | fgets(buf, size, stdin) |
| ★ 프로세스 | vfork() | 자식이 부모 프로세스 공간을 오염시킴 | fork() / posix_spawn() |
| ★ 멀티바이트 | _mbscpy(), _mbscat() | 크기 인자 없음·인코딩 불일치 시 넘침 | _mbscpy_s(), _mbscat_s() |
| ★ 계정 조회 | getlogin() | 정적 버퍼 반환·스레드 간 값이 바뀜 | getlogin_r(buf, size) |
| 문자열 복사 | strcpy(), strcat() | 대상 버퍼 크기를 검사하지 않음 | snprintf() / strlcpy() |
| 형식화 출력 | sprintf(), vsprintf() | 출력 길이 제한이 없어 오버플로우 | snprintf() / vsnprintf() |
| 형식화 입력 | scanf("%s"), sscanf | 폭 지정 없는 %s 는 무제한 입력 | 폭 지정 %31s · fgets() |
| 문자열 토큰 | strtok() | 내부 정적 상태·스레드 안전하지 않음 | strtok_r() |
| 시간 변환 | ctime(), localtime() | 정적 버퍼 반환·재진입 불가 | ctime_r(), localtime_r() |
| 임시 파일 | tmpnam(), mktemp() | 이름 생성과 사용 사이 경쟁조건 | mkstemp() |
| 명령 실행 | system(), popen() | 셸을 경유해 메타문자 주입 가능 | execve() 계열(인자 분리) |
| 난수 | rand(), srand() | 예측 가능·보안 용도 부적합 | getrandom(2), RAND_bytes() |
스레드 safe 한 함수가 제공되지 않는 경우
_r버전 등 스레드 safe 한 대체 함수가 없으면 lock(뮤텍스)으로 호출~지역 버퍼 복사 구간을 직렬화한다. 같은 함수를 부르는 모든 경로가 같은 lock을 쓰고, 에러 경로를 포함한 모든 반환 경로에서 unlock 한다. → Part 7. API 오용 — 5. getlogin()
2. 암호화 실무 기준표
가이드 원문의 원리는 그대로, 권장 값만 현재 기준으로 갱신했다. → Part 2. 보안기능 — 암호화 계열
| 용도 | 쓰면 안 되는 것 | 권장(가이드) | 실무 보완(현재 기준) |
|---|---|---|---|
| 대칭키 암호 | DES, 3DES(신규), RC2/RC4/RC5, ECB 모드 | AES·ARIA·SEED(128비트 이상) | AES-256-GCM 등 인증 암호 모드 권장 |
| 공개키 암호 | RSA 1024비트 이하, RSA_NO_PADDING | RSA 2048비트 이상 + OAEP 패딩 | RSA 3072 이상 또는 타원곡선(ECDSA/ECDH) |
| 해시(무결성) | MD4, MD5, SHA-1 | SHA-224/256/384/512 | SHA-256 이상, 필요 시 SHA-3 |
| 패스워드 저장 | 평문, 단순 해시, 고정 솔트 | 사용자별 난수 솔트 + 일방향 해시 | PBKDF2·bcrypt·scrypt·Argon2(반복 포함) |
| 난수 생성 | rand(), srand(상수), srand(time(NULL)) | HASH_DRBG·HMAC_DRBG·CTR_DRBG | getrandom(2), /dev/urandom, RAND_bytes() |
| 키·자격증명 보관 | 소스 하드코딩, 주석, 평문 설정파일 | 설정파일에 암호화 저장 후 로드 | 권한 제한 파일 + 키 저장소/HSM, 교체 가능 설계 |
3. 양자내성암호(PQC) 전환 — 전자정부·공공 사업이라면 지금 할 일
2012년 가이드에는 없는 주제. 국내 표준과 전환 의무 일정이 이미 확정되어 있다.
전환 일정
| 시점 | 내용 |
|---|---|
| 2024.8 | 국제 표준 확정 — NIST FIPS 203(ML-KEM)·204(ML-DSA)·205(SLH-DSA) |
| 2025.1 | 국내 표준 확정 — KpqC 최종 4종 선정 |
| 2026.11 | 양자기술산업법 시행 — 전환 수요 본격화 |
| 2035 | 국가·공공 전면 전환(정부 목표 시한) |
국내 표준 — KpqC 최종 4종
- NTRU+(상명대) — 키 캡슐화(KEM), 격자 기반
- SMAUG-T(서울대·방첩사) — KEM, 경량 하드웨어에 유리
- HAETAE(서울대) — 전자서명, 빠르고 데이터 크기가 작음
- AIMer(삼성SDS·KAIST) — 전자서명, 대칭키 기반
왜 지금인가
- 전환 의무 대상 600여 기관(중앙부처 18·지자체 243·공공기관 342), KCMVP 양자내성암호 인증 제품은 현재 3건뿐 — 발주가 한꺼번에 몰리는 공급 병목이 예상된다.
- Harvest Now, Decrypt Later: 지금 수집해 두었다가 양자컴퓨터가 나오면 나중에 해독한다 — 오늘 전송한 장기 보관 데이터가 이미 표적이다.
코드 관점에서 지금 할 일
- 암호 인벤토리 작성 — 어디서 어떤 알고리즘·키 길이를 쓰는지 목록화
- 암호 민첩성(crypto-agility) 설계 — 알고리즘·키 길이를 설정으로 교체 가능하게. 코드 관점의 출발점은 단순하다 — 알고리즘 식별자와 키 길이를 상수로 박지 않는 것(Part 2-2 자격증명 관리 계열의 하드코딩 금지 원칙과 동일)
- 장기 보관·장기 유효 데이터부터 우선순위를 매긴다
- 조달 일정 확인 — 검증필 제품 공급 시기를 사업 계획에 반영
PQC 전환의 첫걸음은 새 알고리즘 도입이 아니라 “우리가 어디서 무엇을 쓰는지 아는 것” 이다.
참고 자료
- 행정안전부·KISA, 「전자정부 SW 개발·운영자를 위한 C 시큐어코딩 가이드」(2012.9, 3판)
- 행정안전부, 「정보시스템 구축·운영 지침」(행안부고시 제2012-25호)
- CWE(Common Weakness Enumeration) — cwe.mitre.org, CWE Top 25
- OWASP Top 10, CERT C Coding Standard
- 실무 도구: 컴파일러 경고(
-Wall -Wextra -Wconversion -Wsign-compare), 정적분석(cppcheck, clang-tidy, clang static analyzer), 동적분석(AddressSanitizer, UBSan, Valgrind), 퍼징(libFuzzer, AFL++)