20년 1회차

전자 서명이 제공하지 않는 보안 서비스는 메시지 기밀성이다.

전자 서명은 송신자의 개인키로 메시지(해시값)에 서명하고 누구나 공개키로 검증하므로, 메시지 내용 자체를 숨기지는 못한다. 기밀성이 필요하면 별도의 암호화를 함께 써야 한다.

• 근원 인증: 서명 검증에 성공하면 해당 개인키 소유자가 만든 메시지임이 확인된다.
• 메시지 무결성: 메시지가 한 비트라도 바뀌면 해시값이 달라져 서명 검증이 실패한다.
• 부인 방지: 개인키는 서명자만 가지므로 서명자가 나중에 서명 사실을 부인할 수 없다.

AES는 DES를 대신하여 새로운 표준이 된 대칭 암호 알고리즘이라는 설명이 옳다.

DES의 짧은 키 길이가 취약해지자 미국 NIST가 공모를 거쳐 Rijndael을 선정해 AES로 공표하였다.

• Feistel 구조로 구성된다: AES는 Feistel 구조가 아니라 치환·순열을 반복하는 SPN 구조이다. Feistel 구조는 DES의 특징이다.
• 고성능 플랫폼 전용의 복잡한 구조: AES는 스마트카드 같은 저사양 환경부터 고성능 환경까지 두루 효율적으로 동작하도록 단순하게 설계되었다.
• IEEE가 공표하였다: AES를 공표한 기관은 IEEE가 아니라 미국 표준기술연구소(NIST)이다.

IDS가 방화벽처럼 반드시 내부·외부 네트워크 경계에 위치해야 한다는 설명이 옳지 않다.

IDS는 트래픽을 차단하는 장비가 아니라 감시·탐지하는 장비이므로, 경계뿐 아니라 내부망 구간이나 개별 호스트 등 감시가 필요한 곳 어디에나 설치할 수 있다.

• 호스트 기반·네트워크 기반 구분: 감시 대상(호스트의 로그·파일, 네트워크 패킷)에 따른 일반적인 분류이다.
• 오용 탐지: 알려진 공격의 시그니처(실행 절차·특징)와 비교해 침입을 판단하는 방식이다.
• 비정상 행위 탐지: 정상 행위를 관찰해 만든 프로파일이나 통계적 임계치에서 벗어나는 행위를 침입으로 판단하는 방식이다.

암호문은 $c=121$이다.

RSA 암호화는 $c = m^{e} \bmod n$이고, 모듈러스는 $n = p \times q$이다.

값 대입: $n = 17 \times 23 = 391$
$m^{e} = 8^{3} = 512$

결과: $512 \bmod 391 = 512 - 391 = 121$
따라서 암호문은 121이다. 512는 모듈러 연산 전의 값이고, 391은 모듈러스 n 자체이다.

CCMP는 데이터 기밀성을 위해 AES를 CTR 모드로 이용한다는 설명이 옳다.

CCMP는 AES 기반의 CCM 모드를 쓰며, 기밀성은 CTR 모드 암호화로, 무결성은 CBC-MAC으로 보장한다.

• TKIP는 확장형 인증 프레임워크: TKIP는 WEP 하드웨어에서 동작하도록 만든 암호화·무결성 프로토콜이며, 확장형 인증 프레임워크는 EAP이다.
• EAP는 WEP 하드웨어의 펌웨어 업데이트용: EAP는 다양한 인증 방식을 수용하는 인증 프레임워크이다. 기존 WEP 장비의 펌웨어 업데이트로 적용하도록 고안된 것은 TKIP이다.
• 802.1X는 무결성을 위해 CBC-MAC 이용: 802.1X는 포트 기반 접근 통제(인증) 표준이며, CBC-MAC으로 무결성을 보장하는 것은 CCMP이다.

CC 인증 평가는 PP 평가 → ST 평가 → TOE 평가 순서로 진행되므로 가 → 나 → 다가 옳다.

PP는 제품군에 대한 구현 독립적 보안 요구사항 집합이고, ST는 특정 제품이 PP 등을 바탕으로 작성한 구현 종속적 보안 명세이다. 요구사항 문서(PP·ST)를 먼저 평가한 뒤 실제 평가 대상인 TOE가 ST를 충족하는지 평가한다.

• 가 → 다 → 나: 제품(TOE) 평가가 그 기준이 되는 ST 평가보다 앞설 수 없다.
• 나 → 가 → 다: ST는 PP를 참조해 작성되므로 PP 평가가 먼저다.
• 다 → 나 → 가: 요구사항 문서 평가와 제품 평가의 순서가 완전히 뒤바뀌었다.

클라이언트 측 스크립트(자바스크립트 등)로 입력을 필터링하는 방식은 바람직한 대응이 아니다.

클라이언트 측 검증은 공격자가 브라우저 설정이나 프록시 도구로 쉽게 우회할 수 있으므로, 입력값 검증은 반드시 서버 측에서 수행하고 매개변수화된 질의(Prepared Statement)를 사용해야 한다.

• 웹 서버의 애플리케이션을 거쳐 DB에 전달되는 구조에서 발생: SQL 삽입 공격이 일어나는 전형적인 환경이다.
• DB 무단 접근·자료 유출·변조: 공격 성공 시 나타나는 대표적인 피해이다.
• 사용자 입력값으로 SQL 질의가 완성되는 약점 이용: 입력값이 검증 없이 질의문에 결합되는 점이 SQL 삽입의 근본 원인이다.

쓰기 권한만 있으면 접근 권한을 변경할 수 있다는 설명이 옳지 않다.

유닉스/리눅스에서 chmod로 파일 권한을 바꿀 수 있는 것은 파일 소유자나 root(슈퍼유저)뿐이며, 쓰기 권한은 파일 내용을 수정할 권한일 뿐이다.

• 권한 유형: 읽기(r), 쓰기(w), 실행(x)의 세 가지가 있다.
• 권한 지정 대상: 소유자(user), 그룹(group), 그 밖의 사용자(other)별로 각각 지정한다.
• SetUID: 설정된 실행 파일은 실행하는 동안 실행자가 아니라 파일 소유자의 권한으로 동작한다.

보안 연관(SA)이 양방향 통신 호스트 쌍에 하나만 존재한다는 설명이 옳지 않다.

SA는 단방향 논리 연결이므로, 두 호스트가 양방향으로 안전하게 통신하려면 방향마다 하나씩 최소 두 개의 SA가 필요하다.

• 전송 모드: 상위(전송) 계층에서 내려온 페이로드만 보호하고 원래 IP 헤더는 보호하지 않는다.
• 인증 헤더(AH): 발신지 인증과 데이터 무결성을 제공하며, 기밀성(암호화)은 제공하지 않는다.
• 보안 연관 데이터베이스(SAD): 호스트는 SA 매개변수를 SAD에 저장해 두고 패킷 처리에 사용한다.

계약 종료 시 보유 이용자 정보를 파기할 수 있다는 설명이 옳지 않다.

이 법은 계약이 종료되면 클라우드컴퓨팅서비스 제공자가 이용자 정보를 반환하고, 보유하고 있는 이용자 정보를 파기하여야 한다고 의무로 규정한다. 재량 규정으로 바꾼 것이 오류이다.

• 이용자 정보 유출 시 즉시 과학기술정보통신부장관에게 통지: 침해사고 등의 통지 조항에 규정된 내용이다.
• 이용자 정보가 저장되는 국가의 명칭 공개 요구: 이용자 보호를 위한 정보 공개 조항에 규정된 이용자의 권리이다.
• 법원의 제출명령·영장 없이 이용자 동의 없는 제3자 제공·목적 외 이용 금지: 이용자 정보의 보호 조항에 규정된 내용이며 정보를 제공받은 제3자도 같다.

인증기관은 자신의 개인키로 인증서에 서명한다.

인증서는 사용자의 공개키와 신원 정보를 인증기관이 보증하는 문서이므로, 인증기관만 가진 개인키로 서명하고 누구나 인증기관의 공개키로 그 서명을 검증한다.

• 인증기관의 공개키: 서명 생성이 아니라 인증서 서명을 검증할 때 쓰인다.
• 사용자의 개인키: 사용자가 자신의 메시지에 서명할 때 쓰며, 인증서 발급 서명과는 무관하다.
• 세션키: 통신 데이터를 대칭 암호화하는 임시 키로, 전자 서명에 쓰이지 않는다.

세션키를 무결성 보장을 위하여 공개키로 암호화한다는 설명이 옳지 않다.

하이브리드 암호에서 세션키를 수신자의 공개키로 암호화하는 목적은 세션키를 안전하게 전달하는 기밀성(키 분배)이다.

• 메시지는 대칭 암호로 암호화: 처리 속도가 빠른 대칭 암호로 실제 데이터를 암호화한다.
• 세션키는 의사 난수 생성기로 생성: 통신마다 예측 불가능한 일회용 키를 만든다.
• 사전 공유 비밀키 불필요: 세션키를 공개키 암호로 전달하므로 미리 비밀키를 공유하지 않아도 된다.

해시함수의 충돌저항성을 위협하는 공격은 생일 공격이다.

생일 공격은 같은 해시값을 갖는 임의의 두 입력(충돌 쌍)을 찾는 공격으로, 생일 역설에 따라 출력 공간의 제곱근 수준의 시도만으로 충돌을 찾을 확률이 높아진다.

• 사전 공격: 자주 쓰이는 단어 목록을 대입해 패스워드를 알아내는 공격이다.
• 레인보우 테이블 공격: 미리 계산한 해시 체인 테이블로 해시값에서 원래 패스워드를 역추적하는 공격으로, 역상 찾기에 해당한다.
• 선택 평문 공격: 공격자가 고른 평문의 암호문을 얻어 키를 알아내려는 암호 해독 공격이다.

CBC에서 암호블록 오류가 해당 블록에만 영향을 준다는 설명이 옳지 않다.

CBC 복호화는 현재 평문 블록을 얻을 때 직전 암호블록과 XOR하므로, 한 암호블록의 오류는 그 블록 전체와 다음 블록의 대응 비트까지 두 블록에 영향을 준다.

• CFB의 암호화 병렬 처리 불가: 앞 블록의 암호문이 다음 블록 암호화의 입력이 되므로 암호화를 병렬로 처리할 수 없다.
• ECB의 IV 미사용: 각 블록을 독립적으로 암호화하므로 초기화 벡터가 필요 없다.
• CTR의 블록별 카운터: 평문 블록마다 다른 카운터 값을 암호화해 키스트림을 만들고 평문과 XOR한다.

공공기관의 장이 허가한 경우는 공개된 장소에 영상정보처리기기를 설치·운영할 수 있는 사유가 아니다.

개인정보 보호법은 공개된 장소의 영상정보처리기기 설치·운영을 원칙적으로 금지하고, 법령에서 구체적으로 허용한 경우 등 법에 열거된 사유에만 예외를 둔다. 기관장의 허가는 그 사유에 없다.

• 범죄의 예방 및 수사: 법에 열거된 허용 사유이다.
• 교통정보의 수집·분석 및 제공: 법에 열거된 허용 사유이다.
• 시설안전 및 화재 예방: 법에 열거된 허용 사유이다.

계정 존재 여부 확인에 악용될 수 있는 명령어는 VRFY이다.

VRFY는 서버에 특정 사용자(메일 주소)가 존재하는지 확인하는 명령이어서 공격자가 계정 목록 수집에 이용할 수 있으므로, 보안상 비활성화하는 것이 권장된다.

• HELO: 클라이언트가 서버에 자신을 알리며 세션을 시작하는 명령이다.
• MAIL FROM: 메일 발신자 주소를 지정하는 명령이다.
• RCPT TO: 메일 수신자 주소를 지정하는 명령이다.

정보보호 관리체계(ISMS) 인증을 규정한 제47조는 ｢정보통신망 이용촉진 및 정보보호 등에 관한 법률｣의 조문이다.

조문이 정보통신망의 안정성·신뢰성 확보를 목적으로 하고, 소관 장관이 과학기술정보통신부장관이라는 점에서 정보통신망법임을 알 수 있다.

• 국가정보화 기본법: 국가정보화의 기본 방향과 추진 체계를 정한 법으로, ISMS 인증 조문을 두지 않는다.
• 개인정보 보호법: 개인정보 처리와 정보주체 권리 보호를 다루며, 소관 기관도 개인정보 보호 관련 기관이다.
• 정보통신산업진흥법: 정보통신산업의 육성·진흥을 위한 법으로 정보보호 관리체계 인증과는 관계가 없다.

SYN 쿠키 기법은 클라이언트가 쿠키가 포함된 ACK를 보내오면 그때 세션을 열고 통신을 시작한다는 설명이 옳다.

서버는 SYN을 받아도 연결 정보를 테이블에 저장하지 않고 쿠키로만 응답하며, 돌아온 ACK의 쿠키를 검증해 정상 연결임이 확인된 뒤에야 연결을 생성하므로 연결 테이블 고갈을 막는다.

• SYN 수신 시 연결 테이블에 기록: SYN 쿠키는 바로 이 기록을 하지 않아 자원 소모를 막는 기법이다.
• 중요 정보를 SYN-ACK의 응답(acknowledgment) 번호로 전송: 연결 정보를 담은 쿠키는 SYN-ACK의 응답 번호가 아니라 서버의 순서(sequence) 번호로 전송된다.
• 미완성 엔트리 삭제 대기 시간 결정: 연결 대기 시간(타임아웃)을 줄이는 별도의 대응 방안이며 SYN 쿠키의 동작이 아니다.

PDCA의 점검(Check) 단계에 해당하는 항목은 성과평가이다.

ISO/IEC 27001:2013에서 성과평가는 모니터링·측정·분석, 내부 감사, 경영검토를 통해 ISMS가 효과적으로 운영되는지 점검하는 항목이다.

• 개선: 부적합 사항을 시정하고 지속적으로 개선하는 조치(Act) 단계에 해당한다.
• 운영: 계획한 통제를 실제로 수행하는 실행(Do) 단계에 해당한다.
• 지원: 자원·역량·인식·의사소통·문서화 등 ISMS 수립과 운영을 뒷받침하는 항목으로, 점검 단계가 아니다.

설명에 해당하는 합의 알고리즘은 PoS(Proof of Stake, 지분 증명)이다.

PoS는 연산 경쟁 대신 참여자가 보유한 지분에 비례해 블록 생성 기회를 주므로 채굴 경쟁에 따른 자원 소비 문제를 줄인다. 투표(다수결)로 합의하지 않아 퍼블릭 블록체인처럼 불특정 다수가 참여하는 환경에 쓰인다.

• PoW(Proof of Work): 비트코인의 방식으로, 연산 경쟁 때문에 과도한 자원 소비가 생긴다는 비판을 받는 바로 그 대상이다.
• Paxos: 노드 간 메시지 교환과 다수 동의로 값을 확정하는 합의 알고리즘으로, 참여 노드가 정해진 환경을 전제로 한다.
• PBFT(Practical Byzantine Fault Tolerance): 노드들의 투표(다수결)로 블록을 확정하므로 참여자가 제한된 프라이빗 환경에 적합하다.