함께 배우는 수업 · 컴퓨터/정보

정보 보안과 암호학 기초

정보 보안의 3대 요소(CIA), 대칭키 암호화(AES)와 공개키/비대칭키 암호화(RSA), 단방향 해시 함수(SHA-256)와 솔트(Salt), 디지털 서명 및 HTTPS(TLS) 하이브리드 동작 원리를 학습합니다.

이 수업에서 해 볼 일

  • 암호화·해시·인증의 보안 목적을 구별한다

먼저 알면 좋은 것: 소인수분해와 나머지 연산(모듈러 산술)의 비대칭성 · 해시(Hash)의 단방향 매핑 개념 · 클라이언트-서버 네트워크 통신과 중간자 공격(MITM)

오늘의 목표

가입 없이 시작할 수 있어요. 설명을 읽고, 함께 연습한 뒤, 처음 보는 문제에서 직접 확인합니다.

판단 과정과 비교 사례

보안 요구를 기밀성·무결성·가용성으로 나누어 보자. 내용을 숨기는 것, 변경을 알아내는 것, 필요할 때 사용할 수 있게 하는 것은 서로 다른 목표다.비밀번호 대조에는 원문 복원이 필요하지 않다. 사용자별 솔트와 비밀번호 전용 해시를 사용하면 같은 비밀번호의 동일 해시와 빠른 추측 공격의 위험을 줄일 수 있다.해시만 제시했다고 송신자가 인증되는 것은 아니다. 공격자가 파일과 해시를 함께 바꿀 수 있으면 검증 근거도 사라지므로 신뢰할 수 있는 해시 전달 경로나 MAC·서명을 함께 검토해야 한다.

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)를 사용하는 연결·재개 방식도 있으므로 모든 연결이 같은 인증서 절차를 반복하는 것은 아닙니다.

예제로 살펴보기

앨리스(Alice)가 밥(Bob)에게 극비 문서 M을 보낼 때, (1) 해커가 중간에서 내용을 훔쳐보지 못하게(기밀성) 암호화하려면 누구의 무슨 키로 암호화해야 하는지, (2) 이 문서가 해커가 위조한 것이 아니라 정말 앨리스 본인이 작성했음을 증명(전자서명)하려면 누구의 무슨 키로 서명해야 하는지 각각 답하시오.
  1. 1) 기밀성 보호: - 밥의 것임을 확인한 수신자의 공개키를 사용하는 암호화 방식을 선택하고, 밥은 수신자의 개인키로 복호화합니다. 실제 큰 문서는 대칭키로 암호화하고 그 키를 공개키 방식으로 보호하는 하이브리드 구성을 쓸 수 있습니다. 안전한 알고리즘·구현과 개인키 보호가 전제입니다. 2) 서명과 검증: - 앨리스는 송신자의 개인키로 문서에 대한 디지털 서명을 생성합니다. - 밥은 앨리스의 것임을 확인한 송신자의 공개키와 문서·서명을 서명 검증 알고리즘에 넣습니다. 검증 성공은 해당 개인키로 서명이 생성되었고 서명 대상 내용이 바뀌지 않았다는 근거입니다. 서명은 내용을 숨기지 않으며, '서명을 복호화한다'고 일반화하지 않습니다.
확인: 정보 보안의 3대 요소(CIA)는 기밀성(Confidentiality), 무결성(Integrity), 가용성(Availability)이다.

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 시스템은 비용 설정과 입력 길이 제한을 점검해야 합니다. 이는 보안 설계 지침이며 특정 알고리즘만 법적으로 허용된다는 뜻은 아닙니다.

참고 근거와 확인 범위

설명·예제·문제 구성 및 오류 수정 책임: 프리런. 위 자료는 표시한 주제를 확인하거나 더 읽기 위한 근거이며, 외부 기관의 공식 수업이나 감수본을 뜻하지 않습니다.

참고 자료 연결 점검: 2026-11-02. 제작 방식·검수 범위와 수정 기록에서 확인 범위를 볼 수 있습니다. 오류는 상단의 의견 보내기 또는 contact@freelearn.io로 알려 주세요.

이 단원의 개념서 읽기 →