[Kisa] 암호의 이해와 키 관리 실무 - IOT 보안

"암호의 이해와 키 관리 실무" 에 맞지 않는 주제와 내용이었다.

단순히 위협의 모호한 나열
위협이 구체적으로 어떻게 시도 되었는지.
그래서 어떻게 해결했는지, 또는 어떻게 해결해야 하는지 구체적인 내용이 없음

IOT 위협 사례

사례1 : 스마트 TV와 웹 서버간 SSL 통신시 침입자가 스마트 TV와 웹 서버간 MITM 시도
사례2 : 악성코드가 포함된 영상 파일을 통해 스마트 TV 등 카메라가 내장된 디바이스에 의한 사용자의 사생활 노출
사례3 : 침입자가 스마트 냉장고에 침입해 스팸메일을 대량 발송 할 수 있음

의료분야 사례

센서 : 환자의 건강 정보 노출 및 위변조 가능
단말기 : 스마트 의료 단말기의 인증이 적절하게 이루어지지 않으면, 단말기를 통해 개인정보 유출 가능
센터 : 센터 내 개인정보, 의료정보의 노출 및 위변조 가능

교통분야 실제 사례

2010.3 : Remote Shutdown - 시스템 제어로 원격에서 차
2012.7 : Stolen Cars - OBD(자가진단장치) 취약점을 이용해, 암호키 복사, 스마트키 복제
2012.9 : Hack via Smart Phone App - 앱을 통해 자동차 ECU에 접속 가능
2014.7 : Electric Car Hack - 테슬라 S모델에 접속해 문, 창문을 제어
2015.7 : Remote Hack - 짚체로키를 해킹해 핸들을 조종하고 차를 멈춘 사례
2015.8 : Telematics Hack - OBD 동글을 통해 안드로이드에서 SMS 보내서 CAN에 명령

교통제어 사례
VDS240 마그네틱 센서에서 전달되는 교통상황 데이터에 대한 암호화/인증이 전혀 안되어 있어 VMS(교통표지판) 해킹 가능성이 존재.

항공제어 사례
항공정보교류시스템(ACARS)를 통해 비행기의 컴퓨터 장치(비행관리장치, PMS)에 악성코드를 설치하면 조종사가 보는 계기판의 고도, 방향, 속도 등을 임의로 조작하는 일도 가능하다.

산업제어 사례
스카다 운영자의 USB를 통해 폐쇄망 침투

IOT 환경의 보안 전략

인증
인증 대상의 확대
새로운 인증 대상의 등장
On-Line / Off-Line 을 포함

TPM ( Trusted Platform Module ) 
암호화 프로세서 통합
Random Number Generator
RSA Key generator
SHA-1 hash generator
signature engine

고유ID(비밀키)저장, 암호화키(PCR, AIK, Storage Key 등) 통합 저장

DUKPT(Derived Unique Key Per Transaction) OS
- 이미 POS 단말기에서 쓰이고 있다. 암호화 키 값이 매번 바뀐다.

모니터링
센서들의 보안 관련 이벤트를 모니터링 할 수 있는 환경

Layer 별 보안 기능

Device Layer
- 기기인증 (단말/센서) : ID/PW, PKI, SIM ...
- 무결성 검증 : Platform, Data
- 암호화 : 경량화 알고리즘
- 접근 통제 : 물리적 접근 통제 포함
- TPM
- Firmware / OS 지속적인 업데이트

Network Layer
- D-TLS 기반 인증 및 암호화
- 경량화된 암호화

Application Layer 
- 경량화 보안 매커니즘
- 가상화를 이용한 단말 미들웨어
- 안티멀웨어
- 인증 /인가
- Privacy
- 암호화
- Audit trail

IoT 환경의 보안 전략 - 산업별 보안 Architecture

Security Architecture for IoT

홈 네트워크 건물 인증 - KISA 보안점검 항목이 있다.

차량 보안

Secure CAR - 인증
Secure IXS - X == Any
Secure OTA - 원격 펌웨어 업데이트

Secure H/W module
소형 : SoC
중소형 : eSE
중대형 : TPM

Secure Boot - OS 가 통제권을 갖기 전에 이미지의 서명을 확인하고 실행

IoT 보안 및 관련 암호 기술

한국의 Use Case 를 많이 알려야 표준에 반영된다.

인증 ? 

산업의 활성화를 위한 것인가?

전문가가 되려면 표준 규격을 이해해야 한다.

그리고 커밋을 많이해야 그 오픈소스 프로젝트를 먹을 수 있다.

오픈소스 프로젝트를 차지하게 되면 표준에 영향을 미칠 수 있다.

자바스크립트 20년 하신분을 만났다 -> 스카웃 제의 및 몸값이 엄청나다.

실제 해킹도 전쟁이지만 기술력 보유 자체도 전쟁이다.

oneM2M - 사물인터넷 시스템에 대한 표준화

oneM2M 은 표준화 기관들이 모여서 만든 IoT 표준이다.

ㆍoneM2M 은 자원 기반 구조 (RoA : Resource Oriented Architecture) 를 따르고

CSF는 자원에 대한 동작을 통해서 제공

ㆍ자원은 트리구조를 갖고, 고유 주소(URI) 를 이용해 Addressing 될 수 있는 데이터 구조

ㆍ자원은 CSE(Common Service Entity)에 저장되며, AE(Application Entity)는 자원을 가질 수 없다. 

ㆍAE와 타 CSE는 Mcc(M2M Communication with CSE)와 Mca(M2M Coummnication with AE) 참조 포인트를 통해 CSE의 자원에 동작을 수행함으로써 동작에 해당 하는 CSF를 제공받을 수 있다.

oneM2M 요청/응답 메시지 플로우

CREATE - 리소스 생성

RETREIVE - 리소스에 대한 값 GET

UPDATE - 리소스 값 갱신

DELETE - 리소스 값 삭제
NOTIFY - 리소스에 대한 값을 담아서 통보

oneM2M IoT Open Platform 고도화 현황

다양한 통신 프로토콜 지원 (HTTP, MQTT, CoAP)

인증 기능 : oneM2M 표준 인증

검색 기능 : 디바이스 인덱싱, 검색

관리 기능 : 시스템 설정, 로그, 장애, API 이력 관리

산업 표준 연동 : OCF, Alljoyn

빅데이터 연동 : 변경된 표준 반영, 시스템 연계 확장

표준 규격 : 등록, 데이터관리, 디바이스관리, 구독 및 통지, 위치관리, 보안, 검색, 서비스 과금, 네트워크 서비스 연동, 어플리케이션 및 서비스 계층관리, 통신관리, 그룹 관리

DTLS (Datagram TLS)

 - 레코드 레이어에 epoch, sequence number 필드 추가

 - Handshake 시 패킷 손실을 처리하기 위해 재전송 타이머 사용 (TCP가 아니라서)

 - 프로토콜 손실 reordering, 단편화 처리를 위한 핸드쉐이크 헤더 수정

 - 서비스 거부 공격을 방지하기 위한 stateless cookie 교환

CoAP

Asynchronous transaction model

UDP 기반

보안 모드 : 

No Security : 보안 기능 OFF

Pre-Shared Keys : 사전에 공유된 키를 사용해 AES로 암호화

Raw Public Key Certificates : ECDH를 통해 키를 교환, ECDSA 를 통한 서명.

X509 Certificates : CA에 의해 사인된 서명 값을 사용.

Epoch : 상태 변화가 있을시 Counter 값.

Sequence_number : replay attack 을 막기 위함.

MQTT

ㆍ대역폭이 낮은 통신 환경에 최적화해 개발됨. 

-> 헤더를 가볍게 설계

ㆍ프로토콜이 차지하는 모든 면의 리소스 점유를 최소화 

-> 클라이언트가 예고 없이 연결을 잃을 경우 서버에서 이벤트 발생

ㆍ느리고 품질이 낮은 네트워크의 장애와 단절에 대비 

->반드시 전달되어야 하는 중요 메시지에 대한 전달 보장

ㆍ다수의 클라이언트 연결에 적합한 Publish - Subscribe 구조 

ㆍ신뢰성 있는 메시징을 위한 QoS 옵션 제공 

->반드시 전달되어야 하는 중요 메시지에 대한 전달 보장 

   0 : 메시지가 최대 1번 전달, 유실 가능성 有

   1 : 메시지가 최소 1번 전달, 중복 가능성 有

   2 : 메시지가 단 한번, 정합성 있게 전달

ㆍ개방형 표준 메시징 프로토콜을 지향 

->설치가 쉽다.

송신자가 Broker를 통해 메시지를 Publish 하면 수신자가 메시지를 Subscribe 하는 방식.

OAuth 2.0 지원

Pub / Sub 에 있어서 세가지 메시징 신뢰성을 위한 QoS 레벨 제공

Read More

[Kisa] 암호의 이해와 키 관리 실무 - FIDO

FIDO (Fast IDentity Online) 1.0

FAR (False Acceptance Ratio) : 타인 수락률 (보안성)

FRR (False Rejection Ratio) : 본인 거부율 (편의성)

보통 안드로이드 / 아이폰 지문의 FAR 은 0.002% 로, 50000명이 오면 통과할 수도 있다.

홍채는 0.0001% 로 가장 낮다.

그러나 사실은 Bandwith 로 따지면 패스워드가 가장 안전하다고 볼 수 있다.

지문 템플릿이 유출되면 안되므로 (변경이 불가하다)

ARM 社 에서 TEE (Trusted Execution Environment) 를 개발해 보관.

전세계적으로 서버가 지문 템플릿을 저장하는 경우는 없다.

FIDO Alliance 의 탄생

페이팔에서 도용에 의한 사고율이 0.9%

어마어마한 돈을 들여 FDS 회사 $169M 에 사들였지만 0.3%

참고로 한국은 0.0002% 지만

ActiveX 엄청깔고 공인인증서 도입해야됨...

안되겠다 FIDO Alliance 를 만들자!

FIDO

1. 가입자 인증 후 서버에 공개키 등록
2. 서버가 Challenge 를 생성해서 보내면 클라이언트에서 전자서명 해서 다시 서버로 보냄
3. 개인키 이용 권한 획득 행위를 다양화 (지문 / PIN / 얼굴인식 / 홍채 ...)

• 등록 : 

TEE에서 비대칭키 생성하고 공개키를 서버에 등록하고 Attestation 을 함께 첨부함.

• 인증 :

서버가 보낸 Challenge TEE에서 개인키로 전자서명 해서 서버로 전송하고, 

서버는 등록된 공개키로 이를 검증. 단, 부인방지의 기능은 전혀 없음.

• 거래 확인 : 거래하는 내용에 대해 확인 / 전자서명

인증 과정과 프로토콜은 동일하고, Challenge 와 서명해야 할 원문 데이터도 함께 옴 

• 해지 : 단말에 저장된 이용자의 개인키 삭제

UAF (Universal Authentication Factor) : 모바일 중심 - 패스워드 없이 다양하게 인증

U2F (Universal 2 Factor) : PC 중심 - 패스워드 인증 후 2차 인증

Attestation : 이 공개키의 출처가 어디냐?

CA입장에서 사용자의 환경(USB/보안토큰/TEE)이 안전한지 확인할 방법이 전혀 없다.

사실 키를 관리하는 인증 장치가 다 다르므로, FIDO 에서는 이를 고민했다.

지문을 사용하는지, 패스워드인지, 얼굴 인증인지, 어떤 환경인지?

하지만 Attestation(증명) 이 쉽게 조작되면 안되므로,

제조사에서 FIDO 장치에 대해 인증서를 다 발행해 박아두었다.

공개키 키쌍 / 키길이 / 해시알고리즘 / 저장 위치 / 인증 행위 (PIN/지문/홍채)

등을 metadata에 기록.

원래 클라이언트 (삼성) - 서버 ( 라온시큐어 ) 도 다 호환 된다.

그러나 무결성 검증을 위해서는 서버에 Metadata 를 넣어줘야 하는데,

상업용 표준이다 보니 특히 삼성에서 잘 안준다. 돈 내야 준다.

FIDO 시스템 구성

[외부]

Relying Party Client (뱅킹앱) - HTTPS - Relying Party Server(뱅킹 서버) - FIDO Server

[내부]

FIDO Authenticator - FIDO ASM App - FIDO Client App - Relying Party Client(뱅킹앱)

FIDO Server : FIDO Authenticator 에서 생성된 사용자의 공개키를 등록/관리/검증

FIDO Client : 통신중인 Fido Server의 정책에 따라 인증장치(ASM/Authenticator)를 필터링 하는 역할을 수행하고 FIDO ASM 과의 업무 앱 간 중계 역할을 수행.

FIDO ASM : FIDO Client와 Authenticator 간의 중계역할을 수행하고, FIDO Client 가 요구한 Authenticator로 요청 명령을 전달, 생성된 응답을 Client로 리턴함.

오로지 등록할때 썼던 Fido Client App 에서 요청 했을 때만 

FIDO ASM App 에서 데이터를 준다.

FIDO Authenticator : 생체 인증으로 사용자를 인증, 서버와의 원격 인증을 위한 공개키/개인키 쌍을 생성해 공개키를 서버로 전달하며, 개인키를 이용해 전자서명 수행함.

FIDO METADATA

어떤 인증인지 ? (지문 / 홍채 / 핀 / ...)

전자서명 알고리즘 종류

키가 어디에 저장되는지 ? (TEE / SDCARD / ...)

지문 정보가 어디에 저장되는지? (TEE / SDCARD / ...)

거래 확인 과정에서 TUI 를 사용하는지 ? (Trustzone 에서 띄운 UI)

FIDO UAF Registration (등록)

AppID (안전한 앱인지?) - https://fidotest.com/facetIDList.txt

Assertion : 서명값이라고 보면 됨

Assertion 구조

서버에서 생성한 Challenge 와 부가 정보를 포함해 전자서명.

서버에서는 METADATA를 통해 전자서명 알고리즘을 확인.

assertion = {Sprivatekey(AAID | H(fcparam) | keyID | Counters | PublicKey) | AttestationCert}

fcparam = {appID | chalenge | facetID | channelBinding}

각 항목 설명

challenge : RandomStr

KeyID : FIDO Authenticator 에서 키 쌍과 함께 생성한 키 ㅣ식별자

PublicKey : 이용자의 공개키

Sprivatekey : 제조사가 박은 Attestation 개인키로 서명 원문을 전자서명.

AttestationCert : FIDO Authentication 내 내장된 제조사 인증서

Counter : Attestation 개인키로 몇 번 서명이 이루어졌는가

FIDO Transaction Confirmation(거래 확인 전자서명) 구조

assertion = SprivateKey (AAID | nonce | H(fcparam) | H(TC) | KeyID | Counters )

fcparam = {appID | challenge | facetID | channelBinding}

H( ) : SHA256

KeyID : 전자서명시 사용된 개인키의 키 식별자

TC : 거래 확인용 데이터 Image 또는 Text

FIDO 의 특징

TEE / SE 사용 권장 

허용하지 않은 RP Client 거절 : 가짜 앱 방지

등록 (모듈) 경로 

FIDO 1.0 과 2.0 비교

일단 2.0부터는 Microsoft에서 주도하고 있고, 개념만 같지 스펙이 완전히 다르다.

아직 표준화 작업이 완료되진 않았다.

지원 RP Client : APP -> APP + Browser

통신 프로토콜 : UAF Protocol -> 단순 서명 값 전달

FIDO Client 호출 방식 : Intent, URL Scheme -> Javascript

FIDO Client 제공자 : 3rd Vendor -> Platform Vendor

FIDO Authenticator 제공자 : 3rd Vendor, 단말 제조사 -> Platform Vendor

외부 FIDO 인증장치 표준 연동 : X -> CTAP (USB, NFC, BLE)

번외 : 블록체인 - 작업증명

거래 데이터 : 누구계좌에서 누구 계좌로 돈을 보내겠다.

계좌는 누가 개설하는게 아니다. 그냥 내가 만들면 된다.

ECDSA 개인키 하나 만들고 공개키도 만들고 이걸로 계좌를 만든다.

만약 키를 잃어버리면 거기 안에 있는 비트코인은 평생 찾을 수 없다.

10분에 한번씩 블록이 만들어지고 모든 블록이 이전 블록의 해시값을 갖고있다.

이 해시값은 특별하며, 이걸 먼저 만들기 위해 모두가 경쟁한다.

10분안에 누군가 해시값을 공개하는데 6자리에 해당하는 해시값을 찾아 nonce와 함께 전자서명 해서 공개했는데 

10분안에 누군가가 7자리에 해당하는 해시값을 찾음

9분 50초 안에 누군가 8자리 찾음 ; 이 사람에게 12.5 비트코인을 준다.

작업한 양 만큼 비트코인을 나눠주는 것도 있다.

해커가 블록 하나를 변조하려면 50% 이상의 마이너들의 정보를 동시에 바꿔야 가능하다.

과반이상이 동일한 정보를 갖고 있으면 그걸 맞다고 생각하니까.

Read More

[Kisa] 암호의 이해와 키 관리 실무 - 4일차 암호와 금융 보안

P / NP : 문제를 푸는데 걸리는 시간과 검증하는데 걸리는 시간의 측면에서 바라 봄

P problem : Polynomial time problem - 푸는 시간, 검산하는 시간이 다항식내 끝남
NP problem : Nondeterministic P problem - 푸는 시간 예측 불가, 검산은 다항식 시간 내 끝남 (예 : RSA )

P 문제도 무한하고 NP 문제도 무한하다.
P = NP 인지 P != NP 인지 증명한다면?

만약 P = NP 라면 어려운 문제는 쉽게 풀 수 있는 길이 존재하므로
모든 암호는 다항식 시간 내 풀 수 있는 방법이 존재한다는걸 증명하게 되는 것이다
==> 노벨상

암호 안정성 증명 모델

진짜 암호문을 오라클에 만들어 보냄 ----->
랜덤 스트링을 오라클에 만들어 보냄 ----->

랜덤 오라클 모델로 안전하다고 알려졌지만 깨진 사례가 있음.
최근은 Standard Model 을 사용해서 안전성 증명.

SHA3 는 귀납법을 이용해 안전성을 증명한다.

1. SHA3 를 깨는 방법이 있다 -> 가정
2. SHA3 는 문제 A를 푸는 것으로 다항식 내 풀 수 있다.
3. 하지만 문제 A를 푸는 방법은 알려져 있지 않다.
4. 따라서 SHA3 를 깨는 방법은 없다.

무결성 검증 모델

1. 무결성 검증 기능을 제공하는 모드를 사용한다(CCM / GCM)
2. 평문 암호화 단계에서 평문에 대한 해시값도 함께 암호화 한다.
3. 평문에 대한 MAC 값을 첨부한다. (암호화 키와 MAC 키는 달라야 한다.)
4. 평문에 대한 전자서명 값을 첨부한다.

가용성

현재 컴퓨팅 환경에서 쓸 수 있는 수준의 보안을 적용해야 함.

RSA 1024 : 10ms

RSA 2048 : 80ms

RSA 4096 : 640ms

알려진 암호 공격 기법

CPA (Chosen Plaintext Attack) : 선택 평문 공격

• 상황 : 암호 오라클이 존재하여, 평문을 주면 평문에 대한 암호문을 준다.
• 공격 : 모든 평문에 대한 암호문을 만들어 둔다.
• 조건 : 암호문을 적절한 시간내 얻을 수 있을 때 / 키가 고정된 시스템

KPA (Known Plaintext Attack) : 알려진 평문 공격

• 상황 : 공격자가 평문에 대응하는 암호문 몇개를 알고 있는 경우 
• 공격 : 치환 암호 환경에서 빈도 분석을 활용.
• 조건 : 빈도 분석 공격을 할 수 있을 정도로 평문과 암호문 쌍이 많을 때.

CCA ( Chosen Ciphertext Attack) : 선택 암호문 공격

• 상황 : 복호 오라클이 존재하여, 암호문을 주면 평문을 준다.
• 공격 : 암호문을 조작하거나 생성하여 평문 - 암호화 쌍을 만들어 둔다.
• 조건 : 적절한 시간 내 얻을 수 있을 때 / 키가 고정된 시스템

COA ( Ciphertext Only Attack ) : 암호문 단독 공격

• 상황 : 공격자가 도청을 통해 암호문을 얻는다.
• 공격 : 분석 과정을 통해 평문을 예측한다.
• 조건 : 치환 암호 사용 및 암호문이 많을 때

Replay Attack : 암호문 재전송 공격

• 상황 : 암호문에 대한 평문은 몰라도 암호문을 단순 재전송.
• 공격 : 메시지를 재전송 하여 원하는 것을 얻는다.
• 조건 : 메시지만 암호화 하는 구조 일 때
• 방어 : Timestamp < Nonce < Sequence = One Time Session Key

Reflection Attack : 암호문 반사 공격

• 상황 : 받은 암호문을 그대로 서버에 다시 보냄.
• 공격 : 서버가 클라이언트에게 보낸 명령을 다시 서버가 수행하게 됨.
• 조건 : 세션키가 같을 경우 / 방향에 대한 정보가 없을 경우
• 방어 : 방향에 대한 세션키를 다르게 하고 방향 정보를 추가함. SSL 은 메시지를 암호화 하는 키, MAC 에 사용하는키, 순방향 / 역방향 총 4개를 공유한다.

Session Hijacking Attack : 세션 훔치기 공격

• 상황 : 공격자가 피해자의 개인 정보를 몰라도 로그인
• 공격 : 세션 ID를 훔쳐서 그대로 사용함
• 조건 : IP 확인이나 다른 Factor를 사용하지 않는 경우
• 방어 : 특별한 기능 ( 개인정보 수정 등 ) 은 재인증 한다(패스워드/ARS 등)

MITM : 중간자 공격

• 통신을 가로채서 위변조
• 방어 : 암호화 통신 / 동일키 확인 / MAC / 상호인증 / 재전송,반사공격 방지

암호 프로토콜 강화 기술

Probabilistic Encryption : 확률적 암호

• KPA, COA 방어를 위해 평문 - 암호화 쌍이 1:1이 아니도록 함.
• Encryption(RandomStr + Message) 복호화 이후 RandomStr 삭제

Key Confirmation : 동일 키 확인

• 원래 세션이 존재하는 상태에서 특별한 정보 공유를 위해 키를 나눠가지는 상황
• 클라이언트와 서버가 동일한 키를 갖고 있는지 확인 해야 한다.

Convert Channel : 은닉 채널

• 통신 회선 뿐만 아니라 메모리간 통신에도 적용되는 개념.
• 터널링 / VPN 개념으로 보면 됨.

Forward Secrecy : 전방향 안정성

• 비밀키가 노출되더라도 키 분배 과정의 세션키 안정성에는 여향을 미치지 않음

1. 서버의 개인키(RSA 등)를 Long-term Secret Key로 정의
2. 키 교환 단계에서 사용되고 폐기되는 키는 Short-term Secret Key로 정의
3. Long-term Secret Key 와 Short-term Secret Key는 별개의 키.
4. 세션키를 계산하려면 두개의 키가 모두 있어야 한다.

금융 E2E (End to End) 기술 - Compliance 이다.

일반 E2E : 사용자의 Password 에 대한 기밀성 ( 값을 변경해서 보내겠다 )

확장 E2E : 입력장치로부터 입력된 값만 인식하겠다.

키보드 입력 과정

Key board -> 

커널 -----------------------

8042 MCU -> I8042 driver -> kdbclass driver -> 

윈도우 --------------------

System Message Queue -> Thread Message Queue -> IE/Thread

-> Editor Class

BHO (Browser Helper Object ) 기술

브라우저가 시작될 때마다 함께 로드되어 메모리가 공유되고 있음.

브라우저 창,  HTML Document, Event 에 대한 제어권을 갖는다.

따라서 해결을 위해 실제로 보내는 데이터는 사용자 입력과 다르게

한 바이트씩 암호화해서 히든 필드에 숨겨서 보낸다.

Javascript 기반 가상 키패드 - 문제는 어깨 너머로 볼 수 있다는 것.

멀티 마우스 입력으로 뭘 누르는지 모르게 할 수도 있다. 

아래가 대표적인 예

금융 보안에 대해서는 한국이 선진국이다. ( 이런 키보드 보안 기술은 한국이 최초다 )

OTP (One Time Password)

인증을 위해 사용되는 Password

표준은 많은데 RFC 6338(T-OTP) 를 보통 사용한다.

T-OTP (Time Based OTP)

OTP 서버가 있고, OTP 기기가 있어서 두 값이 같으면 인증됨.

기본적으로 알고리즘은 시간과 Seed를 이용한 HMACwithSHA 이다.

C-OTP (Challenge-Response OTP)

OTP 서버에서 정해준 입력 값(Challenge)을 OTP 단말에 입력해 생성.

단점 :

-비싸다. 단가가 5만원정도.

-단건 이체만 가능하다.

-귀찮고 사용성이 떨어진다.

Read More

[Kisa] 암호의 이해와 키 관리 실무 - 3일차 정보보안 Compliance

정보보안 Compliance 의 과거와 현재

전자정부법 시행령 ( 2014. 12. 09 )에 따르면

제69조 (전자문서의 보관·유통 관련 보안조치) 
① 행정기관의 장은 정보통신망을 이용하여 전자문서를 보관·유통할 때에는 법 제56조제3항에 따라 국가정보원장이 안전성을 확인한 다음 각 호의 보안조치를 하여야 한다.
1. 국가정보원장이 개발하거나 안전성을 검증한 암호장치와 정보보호시스템의 도입·운용
2. 전자문서가 보관·유통되는 정보통신망에 대한 보안대책의 시행
② 행정기관의 장이 제1항의 보안조치를 이행하는 경우에는 미리 국가정보원장에게 보안성 검토를 요청하여야 한다.
③ 제1항 및 제2항에서 규정한 사항 외에 정보통신망을 이용한 전자문서의 보관·유통 관련 보안조치에 관하여 필요한 사항은 국가정보원장이 따로 지침으로 정할 수 있다.

공공기관에 들어가는 시스템은 인증 받아야 한다.

그렇다면 각 웹 브라우저 벤더가 개발 또는 탑재한 HTTPS 는 어떻게 할 것인가?

그들이 CC인증 받는가? 아니다.. 하지만 예외 조항을 두기 시작하면 끝이 없음.

전자금융감독규정

공인 인증서 - 37조

예전에는 반드시 공인 인증서를 사용하도록 되어 있었다.

그러는 와중에 천송이 코트 사건이 터져버렸다.

-> 공인인증서와 ActiveX 때문에 중국인들이 천송이 코트를 못사서 엄청난 피해를 입음.

다만 이것은 공인 인증서 문제는 아니고 그 쇼핑몰이 해외 PG 를 연동하지 않았던 이슈다.

해외 카드를 쓴다면 그 회사의 인증 Compliance 를 따른다. 

즉 해외 PG 를 연동하면 굳이 공인인증서 안써도 되는 거임.

물론 한국인이라면 해외에서 공인인증서 발급이 어려워 문제가 있었을 것이다.

제37조(인증방법 사용기준) 금융회사 또는 전자금융업자는 전자금융거래의 종류·성격·위험수준 등을 고려하여 안전한 인증방법을 사용하여야 한다.

-> 결론적으로 이렇게 수정되었다.

안전한 기준은? 결국 금융회사가 떠안게 된다.

그러나 사실상 페이팔 사고가 0.9% -> 0.3% 

한국은 0.0001% 정도...굉장히 안전한 편이다.

보안 프로그램

하나은행에서 가장 먼저 아이폰 출시와 함께 최초로 인터넷 뱅킹을 출시했다.

다만 그때 법 규정이 없어서 전자 금융 감독원에서 매우 당황하게 된다.

2011년 -

이제서야 '이용자 PC' 가 아니라 '전자적 장치' 로 명시하여 

보안 프로그램을 설치하도록 했다. 

그리고 현재는 이런 규정마저 삭제하여 보안 프로그램을 설치하던 말던 상관없고

대신 사고나면 너네 책임이라고 규정을 바꾸었다.

매체 분리의 법칙 - 34조

예전에는 스마트폰에 OTP 못 넣었다.

이제는 삭제되었고 MOTP 사용 가능해짐. 요새는 스마트폰에 스마트 OTP 사용 가능.

보안카드

예전에 파밍을 이용해 보안카드 몇개만 입력하라고 하고, 

해커는 원하는 보안카드 번호가 나올 때까지 계속 F5 를 입력해서 돈을 빼감.

그래서 규정이 새로 생겼다. 은행에서 한번 물어본 번호를 또 물어보라고

그런데 이후에 이걸 역이용한 메모리 해킹 사례가 발생.

해커가 보안 카드 번호를 가로챈 다음 사용자에게는 에러메시지 띄우고,

실제로 해당 보안 카드 번호를 이용해 돈을 빼감.

그래서 문구 삭제. 사고나면 너네 책임.

웹 어플리케이션 취약점 - 13조

2006년 -

SQL Injection, 업로드 취약점, Cookie Injection, XSS, BOF, 

부적절한 파라미터, 접근통제 취약점, 적절한 환경설정 취약점에 대해서 막으라고 나왔다.

매우 선구적인 사람들이었음. 그 당시에는 한글 문서도 없었고 아는 업체도 없었다.

2015년 -

알아서 해킹 공격에 노출 되지 않도록 대응 조치 해야한다고 수정 함.

홈페이지 관리 - 17조

2011년 - 

관리자 모드에 대한 인증 강화 ( 아이디 / 비밀번호 + 공인인증서 등 )

2015년 - 

공인인증서나 포트 관련 문구 삭제

보안성 심의 - 36조

2015년 - 공공기관은 보안성 심의 좀 면제되도록 수정

2015년 6월 - 자체 보안성 심의 후 결과 보고서를 금감원에 제출하도록 변경.

전자금융거래법

책임 - 9조

1차적으로 금융회사나 전자 금융업자의 책임

2015년 - 

고의나 중대한 과실이 있는 경우 

책임 전부나 일부를 이용자가 부담하게 할 수 있다.

왜냐하면 처음에는 은행에서 다 부담했지만 워낙 파밍이 기승을 부리자

캠페인도 많이 하고 노력해서 사용자에게 알렸음에도 

불구하고 보안카드 번호를 다 입력한 건 사용자 부주의로 볼 수 있음.

전기통신금융사기 피해 환급에 관한 특별법

환급

2014년 - 

ㆍ전기통신금융사기죄 신설 (10년이하 / 1억원 이하)

ㆍ온라인 대출 신청 및 저축상품 해지 시 

금융회사의 본인확인 의무화 (전화인증, 휴대폰 SMS)

ㆍ금융회사는 FDS를 통해 사기임을 탐지한 경우 이체/송금을 지연 및 일시 정지

ㆍ사기이용계좌(대포통장) 명의인에 대해 전자금융거래 제한

모든 전자금융 사기의 핵심에는 대포통장이 있다.

Compliance

많은 Compliance 가 있는데 지금은 가이드 하는 식이다.

하지만 결국 자율과 책임 위주로 가게 될 것이다.

Read More

[Kisa] 암호의 이해와 키 관리 실무 - 3일차 PKI 관련 표준 - PKCS

PKI 관련 표준

CLR 

서버가 받은 인증서의 'CLR 배포 지점' 항목에서 LDAP URL(ldap://) 을 추출해
LDAP DB에 직접 쿼리.
CA에서는 LDAP DB를 항상 갱신함.
폐기된 인증서라도 만료일이 지나면 CLR목록에서 제외.

OCSP

실시간 인증서 상태 검증 프로토콜 (RFC 2560)

• 인증서 폐기 후, 그 즉시 폐기 여부 조회 가능
• 하나의 요청 트랜젝션에 여러 인증서의 상태 요구 가능
• 통신에 대한 무결성을 보증 받을 수 있음
• 인가된 사용자에게만 OCSP 서비스를 제공할 수 있음.
• 프로토콜 자체 보안 기능(Replay Attack)을 제공

서버가 받은 인증서의 'Authority Info Access' 항목에서 OCSP URL을 추출해

OCSP 서버에 쿼리.

OCSP 서버가 LDAP 에 직접 폐기 여부를 조회하고, 조회 결과를 서버에 보내준다.

CA에서는 LDAP DB를 항상 갱신한다.

타기관 LDAP DB와 동기화 된다.

OCSP 서버가 대신하는거 말고 차이가 없어 보이는데...

REPLAY Attack 을 막기 위해 Nonce 를 랜덤하게 생성해서 보낸다. 

암호화 통신을 안한다면 Nonce 가 의미가 있는건지?,

CMP

• 클라이언트에 인증서에 대한 실시간 관리(발급/갱신/폐기) 가능
• CA간 상호인증 등 온라인 서비스 구현 가능
• 통신에 대한 무결성 보증 가능
• 통신 상대방 인증 가능
• 프로토콜 자체 보안 기능 제공

사용자가 인증서 발급 신청을 하면, RA (은행 등) 에서 CA에 발급신청을 하고, 

CA에서는 RA로 인가 코드를 전송한다. 사용자는 이후 공개키 개인키를 생성하고 

RA로부터 전달 받은 인가 코드로 요청 자체를 HMAC 돌려서 CA에 보낸다.

이후 CA는 인증서를 발급 하고, LDAP 에 갱신한다.

결국 CMP 나 PKCS #10 이나 인증서 발급에는 다음과 같은 정보가 필요하다.

CRMF (사용자 식별 정보, 공개키, PoP(Proof of Possession))

POP란 서버에서 보낸 Random 값을 클라이언트의 개인키로 사인한 값이다.

CMP 인증서 발급시 패킷

CMP 인증서 갱신시 패킷
kur 에는 공개키, 개인키 Random 값을 서버의 공개키로 암호화, POP(signature)
+ extraCerts 안에 기존 인증서를 보냄.

발급(ip)과 갱신(kup)시 차이는?

PKCS

PKCS# 1 RSA Standard(PKCS­2/PKCS­4포함) 1.5 1993. 11 

PKCS# 3 Diffie­Hellman Key­Agreement Standard 1993. 11 

PKCS# 5 Password­Based Encryption Standard 1.5 1993. 

PKCS# 6 Extended­Certificate Syntax Standard 1.5 1993. 11

PKCS# 7 Cryptographic Message Syntax Standard 1.5 1993. 11

PKCS# 8 Private­Key Information Syntax Standard 1.2 1993. 11

PKCS# 9 Attribute Types 1.1 1993. 11

PKCS#10 Certification Request Syntax 1.0 1993. 11

PKCS#11 Cryptographic Token Interface Standard 2.01 12

PKCS#12 Personal Information Exchange Syntax Standard 1.0(Draft) 1997. 

PKCS#13 Elliptic Curve Cryptography Standard Project 진행중

PKCS#14 Generator Standard Project 진행중 

PKCS #1 : RSA Cryptography Standard

RSA 암호화/서명 방법과 공개키/개인키에 대한 ASN.1 표기법이 설명되어 있음.

• RSA Public Key /Private Key : ASN.1 표기법 설명
• 데이터 변환 방법 설명 : Integer를 OCTET String 으로 변환하는 방법 설명
• RSAEP/RSADEP : 수하적인 공개키 암호화 스킴 설명
• RSAES-PKCS1-V1_5 : 단순한 패딩 기법을 활용한 RSA 암호화 스킴 설명
• RSASSA-PKCS1-V1_5 : 단순한 패딩 기법을 활용한 RSA 전자서명 스킴 설명
• RSASP1/RSADVP1 : 수학적인 전자서명 스킴 설명
• RSAES-OAEP : RSA 에 대한 공격에 안전한 암호화 스킴 설명(확률적 암호화)
• RSASSA-PSS : RSA 에 대한 공격에 안전한 전자서명 스킴 설명

c = m^e mod n 인데 message가 홀수라면 결과가 홀수가 나오게 된다.

즉, cipher 만 봐도 message가 홀수인지 짝수인지 알게 된다.

그러므로 Padding 과 Encoding 수행.

OAEP 에서 파라미터에 MGF 알고리즘 등이 들어가므로 잘 확인해봐야한다.

PKCS #5 : Password Based Encryption

• PBKDF1/PBKDF2 : 패스워드를 통해 대칭키에서 사용가능한 key와 IV를 추출

 - SALT, ITERATION COUNT( 해시 횟수. 표준은 1024~2048인데 지금은 10만번해야...)

• PBES1/PBES2 : PBKDF1,2 와 대칭키 암호 알고리즘 결합
• PBMAC1 : 메시지 무결성 확인을 위한 MAC 값 생성 프로세스 설명

PKCS #7 : Cryptographic Message Syntax Standard

다양한 암호메시지를 표현하는 표준 (RFC2630)

• Data : 일반 OCTET_STRING 데이터 타입
• Enveloped-Data : 전자봉투 데이터 타입(키 교환정보+암호화된 메시지)
• Signed-Data : 전자서명 데이터 타입 - 다자간 서명을 지원 함
• Signed-and-Enveloped-Data : 전자봉투+전자서명 데이터 타입
• 기타 Useful Type : 인증서, CRL
• Digested-Data : 메시지 축약 타입
• Encrypted-Data : 암호화된 메시지 타입

Signed Data - 전자서명 데이터를 담는 포맷

SignedData ::= SEQUENCE {
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers, - 원본을 Hash 할 알고리즘
     contentInfo ContentInfo, - 원본 데이터
     certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, - 인증서들
     crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, - 인증서 폐기 목록
     signerInfos SignerInfos - 서명자 정보(서명자 ID(발급자정보+시리얼), 추가 의견, 전자 서명

}

SignerInfo - 전자서명 주체에 대한 정보를 담는 포맷 (전자서명 포함)

    

SignerInfo ::= SEQUENCE {

     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber, - 주체 식별자
     digestAlgorithm DigestAlgorithmIdentifier, - 전자서명에 사용할 해시 알고리즘
     authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, - 전자서명 대상 원문
     digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, - 전자서명 알고리즘
     encryptedDigest EncryptedDigest, - 전자서명 값
     unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL - 기타 정보

}

issuerAndSerialNumber는 주체 식별자로, 

  인증서 목록 중 해당 인증서를 찾는 Key 로 사용된다.

DigestAlgorithm 은 SignedData의 digestAlgorithms 중 하나를 선택.

AuthenticatedAttribute 가 없을 시 SignedData의 contentInfo 를 서명한다.

SignedData 검증 및 거래 처리 (PKCS #7)

거래 요청 전문 과 PKCS #7 SignedData를 따로 전송하기 때문에 

실제 거래 내역과 P7 값이 동일한지 확인을 해야 한다.

예 ) 전문 처리

 s_acct=1002777

 r_acct=2222333

 money=100000

전자서명 데이터(법원)

 입금 계좌=1002777

 출금 계좌=2222333

 입금 금액=10 원

위처럼 거래 전문을 수정하는 공격이 실제로 있어 왔고, 

전자 서명 데이터만 법적인 효력을 지님.

따라서 아래와 같이 검증을 해야 한다.

1. SignerInfo-Cert 쌍이 거래 요청자와 일치하는지 비교
2. 전자서명 원문 필드(ContentInfo) Hash
3. SignerInfo 의 Authenticated Attribute 에 있는 원문 Hash 값과 동일한지 비교
4. 서명 시간(Signing Time) 이 있을 경우 허용 시간 내 있는지 확인
5. 서명 검증 (PKCS #1 RSA Verify)
6. PKCS #7의 ContentInfo 에서 거래 데이터 추출 == 거래 요청 전문인지 확인

PKCS #8 - Private-key Information Syntax Standard

다양한 비대칭키 암호 알고리즘의 개인키를 저장하는 규격을 명시.

파일 형태로 보관되는 개인키의 안전한 보호를 위해 PKCS #5 를 이용해 

패스워드 기반의 암호화 된 형태로 개인키를 보관 가능.

PrivateKeyInfo ::= SEQUENCE {
        version                   Version,
        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
        privateKey                PrivateKey,
        attributes           [0]  IMPLICIT Attributes OPTIONAL  - vid=Hash(Hash(주민번호|Random))

}
      Version ::= INTEGER
      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
      PrivateKey ::= OCTET STRING
      Attributes ::= SET OF Attribute

잘못된 Private key Pasword를 입력했는지 어떻게 확인 하는가?

PKCS #5 Padding Remover 의 특성으로 복호화가 되었는지 안되었는지 확인.

1. 키가 달라도 1/256 확률로 패딩 체크를 넘어감 (끝이 01로 끝나면)
2. 개인키는 길기 때문에 30 82 가 맞는지. (81 이하일 수 없다.)

30 82 ..... 쓰레기 .... 01 형태가 되면 키가 잘못 되어도 복호화가 된다.

이것은 1/1600만 확률.

PKCS #10 - Certification Request Syntax Standard

인증서 발급 과정에서 사용자가 CA로 전달하는 "인증서 요청서" 에 대한 규격

SubjectDN 과 공개키, 개인키 소유 여부 확인을 위한 서명 정보로 구성되어 있음.

CertificationRequest : 인증서 요청 규격 (SubjectDN + 공개키 + 서명)

PKCS #11 - Cryptographic Token Interface Standard

암호화 장치를 접근하기 위한 C API 규격.

각 암호화 장치를 Slot 으로 구분하고, PIN 번호를 통해 장비에 로그인 한 후 

장비가 제공하는 기능을 사용 할 수 있다.

자바는 JCE 표준을 따른다

PKCS #11 은 모든 상황을 고려해서 설계되어 있지만, 

HSM 모듈/드라이버가 모든 기능을 다 제공 해야 할 의무는 없다.

PKCS #11 Interface - PKCS#11 Driver - HSM

C = AES_CBC_ENC(Key, IV, M) -> 대용량 데이터는 암호화 할 수 없다.

따라서 하기와 같은 식으로 구현되어 있다.

C_Init(Alg, Key, IV)

C_Update(M1)

C_Update(M2)

C_Update(M3)

C_Update(......)

C_Final(M) => C(Padding)

다만 개발자들이 HSM을 먼저 만들고 PKCS #11 을 Wrapping 하도록 만들기 때문에

HSM 성능보다 100% 를 사용 못하는 경우가 많다. 

암호 함수 호출 과정

1. 드라이버 로드 (libpkcs11.so)
2. 드라이버 초기화 (Multi-Thread or not)
3. Slot 리스트 확인
4. Slot 선택 및 Token 얻기
5. 세션 열기 (From Token)
6. 암호 연산 ... 
7. 세션 닫기

PKCS #12 - Personal Information Exchnage Syntax

사용자 개인정보 (인증서 / 개인키) 등을 안전학 전달 하기 위한 규격.

PKCS #5 와 유사한 PBE 기반의 암호화 방법과 PKCS #7 /#8 규격의 데이터 타입을 지원.

  PFX ::= SEQUENCE {
       version     INTEGER {v3(3)}(v3,...),
       authSafe    ContentInfo, - PKCS #12 규격으로 암호화된 PKCS #7 데이터
       macData     MacData OPTIONAL
   }

-MacData 로 패스워드가 제대로 입력되었는지 확인 할 수 있다. 

PKCS #8 에서 PKCS #5 를 이용하는 것과 달리 단순히 패딩이나 헤더만 보는것이 아니다.

   MacData ::= SEQUENCE {
       mac         DigestInfo,
       macSalt     OCTET STRING,
       iterations  INTEGER DEFAULT 1
       -- Note: The default is for historical reasons and its
       --       use is deprecated.
   }

Local Key ID : 개인키와 인증서 쌍을 확인 할 수 있도록 해 줌.

TSP (Time-Stamp Protocol) 표준

시점 확인 프로토콜( RFC 3161 )

전자 서명 시점을 신뢰된 TSA(Time-Stamp Authority) 가 보증해 줌으로써

전자 문서의 생성 시간을 명확히 확인 (공증) 할 수 있음.

단순히 시간만 증명하는 것이 아니라 이런 문서가 있었다 라는 것을 공증.

원문에 대한 해시값과 시간 정보를 함께 서명한 값 + 시간 정보 

Read More

[Kisa] 암호의 이해와 키 관리 실무 - 2일차 PKI와 관련 표준의 이해

질문 :

전자서명과 암호화를 동시에 하는 방법? : Sign crypto. 어디까지나 학문적인 것.
CA 인증서 업데이트 방법? : 국제 표준 CTL 규격으로 CA 를 업데이트 가능.
개인키 유출의 위험을 최소화 하는 방법? :
 - 보안토큰 등에 보관.
 - Perfect Forward Secrecy (DH)
 - 키를 폐기 가능하도록 할 것.

키 관리 등급
ISO/IEC 24759 에서는 보안 등급 별 키 관리 기능을 명시 하고 있음.
FIPS 140-2 보안 등급에서 S/W 로는 아무리 잘 만들어도 1등급 이다.
보안등급 3 이상을 받기 위해서는 개인키가 암호화 되어 있거나
지식 분산 절차를 사용해 주입 / 출력 되어야 함.

기본적으로 난수 발생, 키생성, 키 합의, 키 분배, 키 주입/출력, 키 저장, 키 제로화 제공

레벨 2 : EAL 2 이상 OS, 물리적 수준은 보안스티커 .
레벨 3 : EAL 3 이상 OS, 물리적 수준은 에폭시 발라서 뜯으면 키가 파괴됨.
레벨 4 : EAL 4 이상 OS, 물리적 수준은 EFP (Environmental Failure Protection) / EFT (Environmental Failure Testing)

HSM - Black Box
SW - White Box - 키를 못찾게 하는 것은 기술력이며, 표준이 없다. 깨진 사례가 많다.
다만, 두 구조 모두 인증을 넣는 개념이 필요하다.

PKI 와 관련 표준의 이해

ASN.1 (RFC 표준 中 매우 기본적인 것)

상대방에게 전달하기 위해서 어떤 방법을 사용 할 것인가?

Decimal / HEX / Big Endian / Little Endian / WIDE String / UTF-8 / ASCII ???

즉, ASM.1 은 추상적인 타입과 값에 대한 표기법이다.

Object ID : 전 세계 유일한 ID

EXPLICIT / IMPLICIT / ANY(VOID) / CHOICE (UNION)

IMPLICIT : 타입을 생략하므로 데이터는 그만큼 줄어듬.
EXPLICIT :  TLV 전체가 VALUE 가 된다. 항상 구조체이다.

ASN.1 : TAG(1byte), LENGTH(가변), VALUE(가변). (TLV)

ASN.1 Notation

BOX :: = SEQUENCE {

    a Integer = 3,

    b Integer = 9

}

ASN.1 DER 

(HEX) : 30 06 02 01 03 02 01 09

TAG : 30

LENGTH : 06

TAG : 02

LENGTH : 01

VALUE : 03

TAG : 02

LENGTH 01

VALUE : 09

TAG

+---------+---------+---------+---------+---------+---------+---------+

|      CLASS(2)        |Structure|          LOW TAG NUMBER(5)          |

+---------+---------+---------+---------+---------+---------+---------+

CLASS : 0 - Universal, 1 - Application, 2 - Context, 4 - Private

STRUCTURE : 0 - Primitive, 1 - Constructed

LOW TAG NUMBER

Universal Tag Number	Description
0	reserved for BER
1	BOOLEAN
2	INTEGER
3	BIT STRING
4	OCTET STRING
5	NULL
6	OBJECT IDENTIFIER (전세계 유일)
7	ObjectDescriptor
8	INSTANCE OF, EXTERNAL
9	REAL
10	ENUMERATED
11	EMBEDDED PDV
12	UTF8String
13	RELATIVE-OID
16	SEQUENCE, SEQUENCE OF (순서)
17	SET, SET OF
18	NumericString
19	PrintableString
20	TeletexString, T61String
21	VideotexString
22	IA5String
23	UTCTime
24	GeneralizedTime
25	GraphicString
26	VisibleString, ISO646String
27	GeneralString
28	UniversalString
29	CHARACTER STRING
30	BMPString

LENGTH

데이터가 11 22 33 44 ... x Byte 인 경우 어떻게 표시할까?

Short Form
04 7F 11 22 33 44 .... 127 Byte

Long Form
Value 의 길이가 128 바이트 이상 일 경우

+---------+---------+---------+---------+---------+---------+---------+

|      1     |                     LENGTH 정보 필드의 크기                    |

+---------+---------+---------+---------+---------+---------+---------+

04 81 80 11 22 33 44 .... 128 Byte

04 82 03 E8 11 22 33 44 .... 1000 Byte

100000 = 186A0
04 83 01 86 A0 11 22 33 44 ..... 100000Byte

INTEGER
2의 보수는 음수이며, 최상위 비트가 1이면 음수로 표현
1의 보수로 만든 다음 1을 더하면 된다.
FF = 1111 1111 -> (-) 0000 0000 -> (-) 0000 0001 = -1

5 : 02 01 05
255 : 02 02 00 FF ( 00을 넣는 이유는 음수가 아님을 표현하기 위해서 )

OID
1.2.840.113549 : 06 06 2A 86 48 86 F7 0D
1.2.840.113549.1 : 06 07 2A 86 48 86 F7 0D 01

1.2.840.113549.1.7 : 06 08 2A 86 48 86 F7 0D 01 07

ASN.1 실습 :

[1] EXPLICIT NULL
A1  02        05 00

[1] IMPLICIT NULL
81 00

[2] EXPLICIT SEQUENCE {}
=> A2 02 30 00

[3] IMPLICIT SEQUENCE {}
=> A2 00
1 0 1 0 0 0 1 0 = A2

BER

Integer 3 =
DER/BER : 02 01 03
      BER : 02 80 03 00 00

BER :  모호한 길이 표현 가능.
0x80 을 넣고 끝에 00 00 을 붙여준다.
30 80 02 01 03 02 01 09 00 00

이제 ASN.1의 DER 인증서를 읽어보자 !

30 으로 시작하니 EXPLICIT SEQUENCE 이고 8이니까 LONG. 2는 길이가 2바이트.
뒤쪽 05 bd 는 VALUE의 크기다. = 1469

더 읽어보기 전에 RFC 2459/3280/5280 문서를 확인해 보자.

4.1.  Basic Certificate Fields

   The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
   tag, length, value encoding system for each element.

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

   CertificateSerialNumber  ::=  INTEGER

   Validity ::= SEQUENCE {
        notBefore      Time,
        notAfter       Time }

   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

   UniqueIdentifier  ::=  BIT STRING

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

수동으로하면 귀찮으니 ASN.1 Editor 로 확인 하면 순서대로

 TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,

version = 2
serialNumber = 18578931 = 01 1B 7D F3
signature = 1.2.840.113549.1.1.11 = sha256WithRSAEncryption

정말인지 인증서 뷰어로 확인 해 보자.

잘 읽은 것을 알 수 있다.

보안 관련 표준을 쉽게 이해하는 노하우

• 이 표준의 목적이 무엇인가 ?
• 종류는 ? ( 데이터 규격 / 인터페이스 / 알고리즘 / 프로토콜 )
• 데이터 기밀성 만족이 필요한지, 방법은 ?
• 데이터 무결성 만족이 필요한지, 방법은 ?
• 개체에 대한 인증이 필요한가 ? 방법은 ?
• 프로토콜이라면 어떤 보안 기능 (재전송 공격 차단 등) 이 있는가?

RFC 는 대부분 하위 호환성을 잘 지키도록 되어 있다.

인증서 검증

기본 검증

• X509 규격에 맞는지?
• 신뢰된 CA로 발급 되었는지?
• 인증서 경로상 서명 검증 결과가 유효한지?
• 인증서가 유효 기간 內 사용되고 있는지
• 인증서의 주체가 올바른지?

확장 검증

• 계층 별 인증서가 올바른지? ( CA / USER )
• 올바른 키 용도로 사용되고 있는지? ( 암호화 / 부인방지 / 전자 서명 등 )
• 올바른 정책 (OID) 으로 사용되고 있는지? ( 은행용 / 증권용 / 보험용 등 )
• 폐기 또는 효력 정지 되었는지? ( OCSP / CRL )

국내 공인인증 확장 검증

• 인증서와 주민번호가 서로 일치하는지?

주민번호는 실제 주민번호를 저장하는것은 아니고 SHA2(SHA2(주민번호|RANDOM)

그러나 Random 값만 알 수 있다면 5시간이면 주민번호 찾을 수 있다.

Random 값은 개인키와 함께 암호화 되어 있는데, 보관에 유의해야 한다.

인증서 상태 검증.. 

하루에 국내에서만 공인인증서 로그인이 5600만건이 이루어지며

비용이 매우 비싸서 자체적으로 LDAP을 통해 인증서 상태 검증 프로세스를 수립하고

당행 발급 인증서가 아닌경우 RA에 쿼리, 타기관이면 금결원 OCSP에 쿼리한다.

문제는 폐기된 타기관 인증서로 계속 은행이나 사이트에 요청하면
돈이 엄청나게 청구되게 된다.
그래서 먼저 가입자 조회부터 하고 인증서 확인 하도록 해야 한다.

X509 확장

기관 키 식별자 : CA의 인증서를 찾는데 IssuerDN 만으로는 부족하므로
CA의 공개키를 해시한 값, CA 인증서 시리얼 번호를 함께 기록함.

주체 키 식별자 : SubjectDN은 얼마든지 동일할 수 있으므로 키를 통해 사용자를 식별하는데 사용. 공개키를 SHA1으로 해시 한 값을 명시.

키 사용 용도 : 공개키와 개인키에 용도를 제한.

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                        -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

예를 들어 C0 = 1100 0000 이므로, 전자서명과 부인방지 용도로 쓸 수 있다.

인증서 정책 : 정책에 따라 범용/은행/보험/카드사/증권사 등의 정책이 존재.

인증서 경로 검증

1. 검증대상 사용자 인증서
2. CA 인증서 저장소
3. 인증 경로의 최대 길이 ( max_path_length ) - 순환 구조인 인증서가 있을 수 있음.
4. 현재 시간 (GMT)
5. 최상위 인증기관 정보 (최상위 인증기관, 공개키 알고리즘, 공개키, 파라미터)
6. 사용자 초기 정책 집합 ( OID, 자식 인증서가 가능한 OID 리스트 등 )
7. 초기 정책 매핑 금지 여부 ( 인증서 내 명시된 인증 정책 매핑 금지 여부 )
8. 초기 명시 정책 여부 ( 사용자 초기 정책 집합과 유효 정책 트리를 비교 할지 여부 )
9. 초기 모든 정책 금지 여부 ( anyPolicy 정책을 허용할지 말지.)

DN 비교 룰
Text 가 같아도 인코딩 형식이 다르면 다르다.
PrintableString 에 한해서 대소문자 구별 안함.
PrintableString은 trim 하여 공백을 없애고 하나 이상의 공백은 공백 하나로 처리.

인증서 키 용도 검증 : 버전 3부터 새로 생겼다.

기본 제한 (Basic Constraints)

CA 인증서인 경우, 현재 인증서로부터 발급 가능한 CA 인증서 계층 수를 제한 가능.
경로 길이 : 0 인 경우, 사용자 인증서만 발급가능. None인 경우 제한 없음.
예를 들어 중간 CA의 Path Length 1인데 하위 CA기관에도 1로 발급 할 경우,
경로 검사가 실패하므로 클라이언트가 이 인증서를 믿지 않게 된다.

KISA에 표준문서가 있다.

Read More

[Kisa] 암호의 이해와 키 관리 실무 - 1일차 (암호학의 기초)

1일차 암호학의 기초

Kerckoff : 결국, 암호 알고리즘을 알아도 키를 모르면 깰 수 없도록 해야 한다.

대칭키

XOR :  같으면 0, 다르면 1

OTP - One Time Pad ( 암호화 )

   - 키 길이와 평문의 길이가 동일함.

   - 가장 빠르고 가장 안전한데 비효율적.

   

OTP - One Time Password ( 인증 )

블럭 암호화 (DES, 3DES, Blowfish, AES, SEED ...)

 - 암호문의 길이는 블록의 배수 ( 16Byte 블록이라면 1Byte 암호화해도 16Byte가 나옴 )

패딩 : 0x남은게 몇 비트인지?

단, 패딩 리무버는 반드시 작동하므로, 평문이 딱 블록의 배수가 된다고 해도

블록 단위가 16Byte 일 때 16을 16개로 채워서 복호화 하는 사람을 배려 한다.

(즉, 16Byte 를 암호화 해도 32Byte 가 나온다.)

스트림 암호화 (RC2, RC4 ...)

 - Key -> Key Derive Function -> Key Stream . 이후 1bit 씩 암호화

AES 

   - AES 192, AES 256 Bit 의 안정성이 실제 키 사이즈 보다 낮음을 증명

     특히 AES 256 은 오히려 AES 128 보다 낮다.

     https://eprint.iacr.org/2009/317.pdf

DES - Feistel 구조

   - 암호화와 복호화 로직이 동일함. 다만 키 스케줄링 순서가 반대일 뿐

   - 그렇다면 대칭성을 가진 키가 있다면 ? 암호화 한번 더 하면 자연히 복호화 된다.

   - Brute Force 에 취약하다고 밝혀져 3-DES 가 나오게 됨.

암호화 모드 (https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)

IV - CBC, CFB, OFB, CTR

암호문의 길이를 평문 길이에 맞춤 : CFB, OFB, CTR

암호문 변조 확인 : GCM, CCM

CBC : 그것만 없으면 가장 안전함.

ECB 모드(Key, Padding) : 상당히 짧은 데이터를 암호화 할 때 정도만 쓰인다. 

왜냐하면 한개의 블록만 해독되면 나머지도 해독 됨.

CBC 모드(Key, IV, Padding) : 가장 안전하고 가장 많이 쓰는데 ...

PKCS5  패딩 오류가 결합되면 가장 취약함. 

처음 IV로 XOR 하고 키 알고리즘으로 암호화 한다. 

이후는 나온 암호문 블록이 IV가 되서 반복한다.

CFB 모드(Key, IV, NOP) : CBC 다음으로 안전한데, 구현이 좀 어렵다.

블록 암호화를 스트림 암호화 처럼 구성해 Padding 필요 없음

IV를 암호화 한 다음 스트림 단위로 자르고, 평문이랑 XOR 한다. 

이후 이 스트림이 다시 IV가 됨.

OFB 모드(Key, IV, NOP) : 한번 더 암호화 하면 평문 나와서 취약함. 좀 속도가 빠르긴 함.

Padding 필요 없음

CTR 모드(Key, IV, NOP): 한번 더 암호화 하면 평문 나옴. 

다만 이렇게 되지 않도록 Shift 등, 보완해서 쓴다. 

다른 모드에 비해 평문 수정이 쉽다. 

IV를 1씩 증가시켜서 암호화 시킨 다음, 평문과 XOR 한다.

GCM 모드(Key, IV,  AAD, NOP) : 

CTR과 동일한데,

Additional Auth Data 로 암호문 블록을 계속 XOR 해서 Auth Tag를 만들어 낸다.

이걸로 무결성 검증이 가능하다.

CCM 모드(Key, Nonce, AAD, Tlen, NOP)

CTR과 동일한데 안쓴다.

문제 : IV 를 찾아라 !

암복호화 엔진을 변경하려고 하는데, CBC모드를 사용하고 있어
기존에 사용되던 Key 와 IV를 알아내야 한다.
그러나 IV는 해당 엔진 내에 화이트박스 처리 되어있어 알 수 없는 상황.
즉,
Encrypt (Key, IV, 평문) -> 암호문
이 아니라
Encrypt (Key, 평문) -> 암호문

이렇게 CBC 모드의 IV 가 함수 자체에 내장되어 있는 경우 어떻게 IV를 찾는가?

0을 CBC 로 암호화 하게되면 

0 XOR IV == IV -> enc (IV)

따라서 다시 ECB dec 하면 IV 가 나오게 된다.

Oracle Padding (CBC)

패딩 오류가 안나고 통과할 때 까지 두번째 블록을 변경해서 날려본다.

결론 : AES 128bit GCM 쓰면 된다. 

비대칭키

RSA (2048) : 소인수 분해. 암호화, 전자서명

DSA (1024) : 이산대수. 전자서명

DH (1024) : 이산대수. 키 교환

ELGamal (1024) : 이산대수. 암호화. 전자서명

ECDH (256) : 타원곡선 상의 이산대수. 키 교환

ECDSA (256) : 타원곡선 상의 이산대수. 전자서명

KCDSA (1024) : 이산대수. 전자서명

키 길이가 괄호 bit 이상이면 안전하다 라고 알려져 있음.

적당히 작은 e를 써야하는데 65537 을 쓴다. 너무 작은 값을 사용하면 취약하다.

RSA - 암호문은 확률적으로 계속 변경된다. 어떻게?

( 하나의 평문에 대응하는 암호문이 많다 )

-> 패딩을 쓰레기값으로 넣어줘서 전체 값이 랜덤하게 변경되도록 한다.

10 G 메시지가 있다고 치자.

이거 RSA로 암호화 하면 너무 오래걸린다. -> 해시해서 쓴다.

MD5 - 알고리즘 자체에 취약점이 발견되어 사용 불가.

SHA1 에서 2^80 메시지만 갖고 있어도 100% 충돌을 발견 할 수 있다.

 전자 서명에서 사용 할 수 없다. 

SHA2 에 256비트 많이 쓰는데 알고리즘 취약점이 나올 확률이 있다.

SHA3 - SHA2 보다 3배정도 느리지만 앞으로 많이 쓰일 것으로 보인다.

서명 : 메시지를 해시 하고 개인키로 암호화해서 메시지와 함께 보내면 

공개키 연산이 더 빠르다 -> 작은 소수를 썼기 때문이다.

Random Generator 가 실제 난수가 아니기 때문에

컴퓨터가 랜덤한 Seed 를 만들지 못하고 Sha 도 다양성이 낮으면

낮은걸 따라가므로 128비트 정도의 안정성 밖에 없다.

Read More

Cloud Sec 2016 관람 후기

너무 늦은 감이 있지만 당시 정리 했던 걸 기록하기 위해 올림.

1.       개요

Cloud 현황, 시장 상황, 관련 솔루션들 소개

-일시 및 장소

2016/9/8, 서울 리츠 칼튼 호텔 그랜드 볼룸

2.       요약

Cloud Provider가 되려면 다양하고 복잡한 규정을 다 준수해야 함.

관련한 규정들은 전 세계 각국에서 2010년 이전부터 계속 심화되고 추가되었기 때문에

AWS, Azure, Google Cloud 정도만 이러한 규정을 모두 준수 가능한 상황.

즉 Cloud Provider 시장은 위 3 회사가 거의 독점하고 있으며, AWS가 주창한

보안 책임 공유 모델에 따라 Cloud Provider가 직접 해주지 않지만 반드시 해야하는 보안 (방화벽, 각종 설정, 암호화, 업데이트 등)과 전통적인 Private Cloud 과 Public Cloud 의 브릿지 역할을 해주는 보안 솔루션 시장만이 남아있는 상태로 보임.

금일 발표 대부분이 이러한 솔루션들 이었다는 것이 그 사실을 대변함.

3.       주요 행사 내용

기조 연설 1 : Take Control – Trend Micro, Bill McGee

불합리한 두려움에 대하여 : 비행기보다 자동차가 더 위험하듯, 당신의 데이터 센터보다 클라우드가 더 보안성이 좋다.

기조 연설 2 : Security and Compliance in AWS Cloud – AWS, Stanley Chan / Richard Busby

AWS 발전 가능성 : 우리 로드맵의 90%는 고객에 의해 제안된 것이다. 또한 AWS는 당신의 데이터가 어떤 하드에 저장 되어 있는지 모른다.

기조 연설 3 : 클라우드 환경에서의 보안 위협과 대응 방안 – 더존비즈온, 송호철

솔루션 소개 : QR코드로 로그인 하고, 지도에 간편히 찍어서 해당 위치를 벗어나면 접근이 불가하도록 가능하게 하는 특허가 있다. 서버는 프로그램 실행 화면만 보내주고, 클라이언트는 입력 값만 전송하는 방식으로 보안 시스템을 구성 가능하다.

기조 연설 4 : The Journey to the Cloud Security – CSA Korea, Thomas Park

Cloud 역사 및 시장 현황 : 2012년, 관공서에서 클라우드 쓰지 말라는 공문이 내려왔었으나 작년엔 클라우드 발전법을 한국에서 세계 최초로 제정하여 가산점까지 준다.

Track 1–1 : Cloud 관제서비스 고려 사항 – SK 인포섹, 박정현

솔루션 소개 : 방화벽 이벤트는 너무 많아서 소화 하기 매우 어려운데, 우리는 빅데이터 활용 방식으로 소화한다. 보호 해야할 자산이 얼마나 있는지 확인하고, 해커도 RIO 를 따진다는 사실을 기억하라. 즉 완벽한 보안 보다는 다른 서비스 보다 더 뚫기 어렵다는 상대적인 사실이 해커에게는 크게 작용한다. 이 때 서비스 근간을 흔들 보안은 AWS/Azure 가 관리하고 우리는 접근제어, 암호화, 무결성, 네트워크, 방화벽 등을 관리 한다.

로그가 많아지면 과금 비용도 우리가 내주고, GW / Host 방식 모두 지원한다.

Track 1-2 : 아마존 클라우드에서의 보안 적용 방안 – TrendMicro, 양희선

         솔루션 소개 : 서버, 스토리지, DB, 네트워크, 지역, 가용성 등은 AWS가 책임

나머지 로그, 콘텐츠, 미들웨어, 어플리케이션 등은 모두 고객이 관리해야 하는데, 우리가 책임져 주겠다. Auto scaling에 대응 가능하고, GW / Host 방식 모두 지원한다.

Track 1-3 : 클라우드 시대의 네트워크와 보안 – VMware, 윤준호

트렌드 : Private Cloud + Public Cloud = Hybrid Cloud. 시장은 이미 이러한 방향으로 나아가고 있는데, 솔루션 도입에 있어서 자동화가 얼마나 잘 되는가가 큰 요소이다.

Track 1-4 : 클라우드 인프라 자원 및 DBMS 관리 사례 – 굿모닝아이텍, 권중술

패스워드 관리 방안 : 보안이 취약해서 뚫리는게 아니라 기본 계정/패스워드가 문제이다.

우리는 비밀번호를 OTP 형식으로 관리해주고, 어플리케이션의, 하드 코딩 된 비밀번호도 전부 지원해 준다. 이런 방식의 관리는 규모가 커질 수록 수동으로는 절대 할 수 없으니, 우리의 솔루션을 이용해 보라.

Track 1-5 : 하이브리드 클라우드의 효율적인 보안 적용 – 제뉴버, 이상조

Host / GW : 오늘 계속 나온 이야기로, 클라우드 보안에는 Host 방식과 GW 방식이 있다. Host 방식이 리소스를 잡아먹고 설치가 필요하다는 이슈가 있으나 장애가 발생하면 그 서버 한대에만 영향을 미치고, Auto Scaling에 대응 가능하고, VM간 공격에 대해 차단이 가능하므로 더 좋다.

4.       사진

시작 전 기대되는 오늘 행사. 행사에 한시간 반 전에 갔지만 얼리버드 상품은 못 받음.

Trend Micro, Bill McGee. 클라우드에 대한 불합리한 두려움에 대하여

이외에도 여러가지 아이디어가 좋았던 더존의 보안 솔루션.

부스 사진

Read More

블루본 (BlueBorne) - Bluetooth 취약점과 탐지(Detector) 앱 분석

이 글이 국내에서는 BlueBorne 에 대한 최초의 포스팅이 될 것 같다.

먼저 BlueBorne 에 대해서 알아보고,

Armis 社의 BlueBorne Detector 앱을 열어서 

어떤식으로 Detect 하는지 확인해 본다.

BlueBorne 이란?

Armis security 에서 17년 9월 12일 
8가지 Bluetooth 취약점 Collection 인 BlueBorne 을 발표 했다.

Bluetooth 관련 프로세스는 모든 OS에서 높은 권한을 갖고 있기 때문에
해당 프로세스를 exploit 하는데 성공한다면 자연히 디바이스의 통제권을 얻을 수 있다고 볼 수 있다.

Blueborne 은 악의적인 기기와 연결되어 있지 않아도 되고, 검색 가능 모드가 아니어도 상관 없는데다 Android, Linux, Windows, iOS 등 거의 모든 컴퓨터, 모바일기기, IoT 제품에 적용된다.

즉, Blueborne는 블루투스 기능을 갖고있는 약 80억개의 Device 에 적용되어 스펙트럼이 매우 넓으면서도 공격 성공시 막강한 권한을 갖게 되는 것이다.

BlueBorne Collection의 CVE 목록은 다음과 같다.

ㆍAndroid
 CVE-2017-0781 : Remote Code Execution Vulnerability #1
 CVE-2017-0782 : Remote Code Execution Vulnerability #2
 CVE-2017-0783 : The Bluetooth Pineapple in Android Man in The Middle attack
 CVE-2017-0785 : Information Leak Vulnerability

ㆍLinux
 CVE-2017-1000250 : Information leak vulnerability
 CVE-2017-1000251 : Linux kernel RCE vulnerability

ㆍWindows
 CVE-2017-8628 : The Bluetooth Pineapple in Windows – Man in The Middle attack

ㆍiOS
 CVE-2017-14315 : Apple Low Energy Audio Protocol RCE vulnerability



위의 CVE-2017-8628(Windows) 과 CVE-2017-0783(Android) 내용을 보면 같은 취약점인걸 알 수 있다.

왜 그럴까?

사실상 블루투스 프로토콜은 구현 하기가 어렵기 때문에,
벤더들은 대부분 프로토콜 가이드라인 대로 하나씩 구현 하게 된다.
(Wifi 스펙은 450p 인데 블루투스 스펙은 무려 2822p)
즉, 대부분 취약점이 발견되었을 때 다른 플랫폼에서도 동일하게 발견 되는 것이다.

더 자세한 정보는 armis 공식 홈페이지의 blueborne 소개 자료를 확인해 보면 된다.

아직까지 관련 보안 패치는 올라오지 않았는데 무시무시한 영상들이 올라와있다.

Demo : Android 

Demo : Windows

Demo : Linux

패치가 나오기 전까지는 bluetooth 를 꺼놓는게 좋을 것으로 보이며, 

리눅스인 경우 CONFIG_CC_STACKPROTECTOR 를 적용해 빌드하면 그나마 CVE-2017-1000251 를 DoS 정도로 완화 할 수 있다.

BlueBorne Detector

또한 pastebin 에 blueborne detector 로 추정되는 소스코드의 일부가 올라와 있어서 찾아보았는데 이미 detector 앱이 나와있었다.

코드 일부 :  https://pastebin.com/RhN6mkqd
앱 : 

https://play.google.com/store/apps/details?id=com.armis.blueborne_detector

Detector 는 확인 결과 두가지 기능으로 이루어져 있다.

1. 자신의 모바일 기기가 BlueBorne 에 안전한지 본다.

해당 함수는 isVulnerable 인데, 내용이 별로 없다.

Smali Code - VulnerabilityUtils.smali

.method public static isVulnerable()Z
.locals 4

.prologue

...... 생략 .......

.line 34
.end local v0 # "securityPatchDate":Ljava/util/Date;
:cond_1
invoke-static {}, Lcom/armis/blueborne_detector/VulnerabilityUtils;->getSecurityPatchDate()Ljava/util/Date;

move-result-object v0

.line 35
.restart local v0 # "securityPatchDate":Ljava/util/Date;
if-eqz v0, :cond_2

sget-object v2, Lcom/armis/blueborne_detector/VulnerabilityUtils;->SAFE_DATE:Ljava/util/Date;

invoke-virtual {v0, v2}, Ljava/util/Date;->before(Ljava/util/Date;)Z
...... 생략 ......

위와 같이 직접 공격을 해보고 취약한지 보는건 아니고

단순히 패치 날짜를 보고 판단하게 된다.

2. 내 주변 Bluetooth 기기들이 안전한지 확인

이 기능은 매우 실망 스러웠다.

Mac 주소를 엄청나게 하드코딩 해둔 뒤

제조사를 파악하고

그 제조사의 이름에 따라 Risk 한지 아닌지를 파악한다.

그림에 High Risk 라고 나오는건 MAC 주소가

24:4B:03 으로 시작되므로 아래 하드코딩된 정보에 따라

취약하다고 판단하게 된다.

Smali Code - Manuf.smali

const-string v3, "24:4B:03"

aput-object v3, v1, v2

const/16 v2, 0x77

Armis가 취약하다고 판단하는 제조사는 Apple 부터 시작해서 ZTE 까지 거의 모든 제조사이다. 

즉, 이름이나 MAC 주소로 제조사가 판단되면 무조건 취약하다고 하는 건데

이딴식(?)으로 만든 이유에 대해

1. 구체적인 POC 를 공개하기 싫어서 (공개되면 큰일이긴 함)

2. 만들기 귀찮아서... 

등의 추측을 하고 있다.

결론적으로, 추후 패치가 나올지는 모르겠지만
현재는 Vulnerability Detector 가 아니라 그냥 Manufacturer Detector 라고 볼 수 있겠다.

Read More