개념 정리
정보 보안과 암호학 기초
단원 개요
정보 보안의 3대 요소(CIA), 대칭키 암호화(AES)와 공개키/비대칭키 암호화(RSA), 단방향 해시 함수(SHA-256)와 솔트(Salt), 디지털 서명 및 HTTPS(TLS) 하이브리드 동작 원리를 학습합니다.선수 개념
필수 키워드:기밀성 (Confidentiality)암호화무결성 (Integrity)해시 함수, MAC, 디지털 서명가용성 (Availability)양방향 암호화의 두 가지 패러다임 비교사용하는 키동일한 비밀키 1개 공유공개키(Public Key)개인키(Private Key)
1
정보 보안 3대 요소(CIA Triad)와 대칭키 vs 공개키 암호화
•
정보 보안의 3대 핵심 목표 (CIA Triad):
1
기밀성 (Confidentiality): 인가된 사용자만 정보 내용을 볼 수 있도록 보호 (도청 방지 ➔ 암호화로 달성).
2
무결성 (Integrity): 데이터가 전송·저장 중에 허가 없이 위변조되지 않았음을 보장 (해시 함수, MAC, 디지털 서명으로 달성).
3
가용성 (Availability): 정당한 사용자가 필요할 때 언제든 서비스를 중단 없이 이용할 수 있음 (DDoS 방어, 서버 이중화로 달성).
•
양방향 암호화의 두 가지 패러다임 비교:
| 비교 항목 | 대칭키 암호화 (Symmetric Key) | 공개키 / 비대칭키 암호화 (Public Key) |
|---|---|---|
| 사용하는 키 | 암호화 키 복호화 키 (동일한 비밀키 1개 공유) | 공개키(Public Key)와 개인키(Private Key) 한 쌍 |
| 대표 알고리즘 | AES, ChaCha20 등 | 암호화에는 RSA-OAEP 등, 키 합의에는 ECDH 등 |
| 연산 특성 | 대용량 데이터 암호화에 적합 | 주로 인증·키 설정 등에 사용하며, 속도 차이는 알고리즘과 환경에 따라 다름 |
| 키 관리의 과제 | 상대방과 비밀키를 안전하게 공유해야 함 | 공개키는 공개할 수 있지만, 그 키가 실제 상대방의 것인지 인증해야 함 |
핵심 원리
공개키 암호화와 디지털 서명을 구분하세요. 암호화는 수신자의 공개키로 내용을 보호하고 수신자의 개인키로 복호화합니다. 서명은 송신자의 개인키로 생성하고 공개키로 검증합니다. RSA-PSS·ECDSA·EdDSA 같은 서명 알고리즘을 단순히 '개인키로 암호화하고 공개키로 복호화'하는 방식으로 일반화하면 안 됩니다. 검증에 쓸 공개키의 소유자도 확인해야 합니다.2
단방향 해시 함수(SHA-256), 비밀번호 솔팅(Salting), HTTPS의 비밀
•
암호학적 해시 함수 (Cryptographic Hash Function - SHA-256, SHA-3):
•
복호화 키 자체가 존재하지 않는 단방향(One-way) 함수입니다. 입력 길이가 1바이트든 10GB이든 항상 고정된 길이(SHA-256은 256비트 = 16진수 64자리)의 해시 다이제스트를 출력합니다.
•
눈사태 효과 (Avalanche Effect): 원본 데이터에서 점 하나(1비트)만 바뀌어도 결과 해시값이 완전히 뒤바뀌므로 파일 위변조 검증과 블록체인 연결에 쓰입니다.
•
비밀번호 저장과 솔트(Salt): 비밀번호는 평문이나 빠른 단일 해시가 아니라, 사용자마다 다른 무작위 솔트와 적절한 연산 비용을 적용한 비밀번호 전용 해시로 저장합니다. 새 시스템에서는 Argon2id 등을 우선 검토하고 환경에 따라 scrypt·PBKDF2 등을 선택합니다. 솔트는 미리 계산한 해시 표의 재사용을 어렵게 하고 연산 비용은 대입 공격을 늦추지만, 유출 뒤 약한 비밀번호가 추측될 가능성까지 없애지는 않습니다.
•
HTTPS (TLS)의 하이브리드 암호화 메커니즘:
•
일반적인 인증서 기반 TLS 1.3 연결에서는 서버 인증과 통신 키 설정의 역할을 나누어 이해해야 합니다:
1
클라이언트는 인증서의 신뢰 경로·호스트 이름·유효 기간 등을 검사하고 서버의 서명으로 키 소유를 확인합니다. (EC)DHE 키 합의로 공유 비밀을 만들고, 여기서 통신에 쓸 대칭키를 유도합니다. RSA로 세션키를 암호화해 전달하는 것이 TLS 1.3의 방식은 아닙니다.
2
실제 데이터는 AES-GCM 또는 ChaCha20-Poly1305 같은 대칭키 기반 인증 암호(AEAD)로 암호화하고 변조도 검출합니다. TLS 1.3에는 미리 공유한 키(PSK)를 사용하는 연결·재개 방식도 있으므로 모든 연결이 같은 인증서 절차를 반복하는 것은 아닙니다.
풀이
1) 기밀성 보호:
•
밥의 것임을 확인한 수신자의 공개키를 사용하는 암호화 방식을 선택하고, 밥은 수신자의 개인키로 복호화합니다. 실제 큰 문서는 대칭키로 암호화하고 그 키를 공개키 방식으로 보호하는 하이브리드 구성을 쓸 수 있습니다. 안전한 알고리즘·구현과 개인키 보호가 전제입니다.
2) 서명과 검증:
•
앨리스는 송신자의 개인키로 문서에 대한 디지털 서명을 생성합니다.
•
밥은 앨리스의 것임을 확인한 송신자의 공개키와 문서·서명을 서명 검증 알고리즘에 넣습니다. 검증 성공은 해당 개인키로 서명이 생성되었고 서명 대상 내용이 바뀌지 않았다는 근거입니다. 서명은 내용을 숨기지 않으며, '서명을 복호화한다'고 일반화하지 않습니다.
3
웹 애플리케이션 3대 보안 취약점: SQL Injection, XSS, CSRF
•
SQL 인젝션 (SQL Injection):
•
사용자 입력란(로그인 창 등)에
' OR '1'='1' -- 같은 악의적인 SQL 구문을 주입하여 데이터베이스 쿼리 논리를 조작하고 인증을 우회하거나 DB 전체를 탈취하는 치명적 공격입니다.•
방어법: 데이터 값은 Prepared Statement (Parameterized Query)의 매개변수로 전달해 SQL 구문과 분리합니다. 테이블·열 이름처럼 일반적으로 매개변수로 바인딩할 수 없는 식별자는 미리 정한 허용 목록에서 선택해야 합니다.
•
XSS (Cross-Site Scripting, 사이트 간 스크립팅):
•
공격자가 게시판 글이나 댓글에 악성 자바스크립트(
<script>...</script>)를 몰래 심어두어, 다른 일반 사용자가 그 글을 열람하는 순간 브라우저에서 스크립트가 실행되어 세션 쿠키나 개인정보를 탈취하는 공격입니다.•
방어법: HTML 본문·속성·URL 등 출력되는 문맥에 맞는 인코딩과 안전한 DOM API를 사용합니다. HTML을 허용해야 할 때는 검증된 정화 도구가 필요하며, HTML 문자 이스케이프만으로 모든 문맥이 안전해지지는 않습니다.
HttpOnly는 쿠키의 자바스크립트 접근을 막지만 XSS 자체나 공격자의 모든 동작을 막지는 않습니다.•
CSRF (Cross-Site Request Forgery, 사이트 간 요청 위조):
•
사용자가 은행이나 웹 서비스에 로그인된 상태에서 피싱 사이트나 이메일 링크를 클릭했을 때, 브라우저가 자동으로 쿠키를 실어 보내는 점을 악용해 사용자 몰래 비밀번호 변경이나 송금 요청을 서버에 전송하는 공격입니다 (CSRF 토큰과
SameSite 쿠키 설정으로 방어).주의할 점
비밀번호 저장에는 평문이나 단순 MD5·SHA-1·SHA-256 대신, 솔트와 적절한 비용 설정을 갖춘 전용 비밀번호 해시를 사용하세요. Argon2id를 우선 검토하고 지원 환경·요구 사항에 따라 scrypt·PBKDF2 등을 선택합니다. 기존 bcrypt 시스템은 비용 설정과 입력 길이 제한을 점검해야 합니다. 이는 보안 설계 지침이며 특정 알고리즘만 법적으로 허용된다는 뜻은 아닙니다.핵심 요약
- ✓정보 보안의 3대 요소(CIA)는 기밀성(Confidentiality), 무결성(Integrity), 가용성(Availability)이다.
- ✓대칭키는 대용량 암호화에 적합하고, 공개키 방식에서는 키의 소유자를 인증하는 절차도 필요하다.
- ✓공개키 암호화는 수신자의 공개키와 개인키를, 디지털 서명은 송신자의 개인키로 생성하고 공개키로 검증하는 별도 절차를 사용한다.
- ✓TLS 1.3은 인증과 키 설정 뒤 AEAD로 데이터를 보호한다. 비밀번호는 솔트와 비용 설정을 갖춘 전용 해시로 저장하며, 해시 유출 뒤의 추측 위험도 고려한다.