김보안의 블로깅
  • 🏠 Home
  • 📚 Project
    • Blockchain
      • 🎦 PickMe
      • 🎦 IoTC
      • 🎦 Blackchain
      • 📃 Gemology
      • 🎦 PickMe
      • 🎦 PickMe
    • AI
      • 👋 A.I. Dream Reader
      • 🎦 A.I. Dream Reader
    • Security
      • 🎦 SNAC
    • Education
      • 🎦 Smart Lecture
  • 🤸‍♂ Hobby
    • Music
      • Violin
      • Guitar
      • Piano
      • Drum
    • Flower
      • Flower Certificate
    • Sport
      • Ski
      • Skateboard
      • Golf
      • Boxing

2018년 5월 24일 목요일

2018 삼성 탈레스 HSM 세미나

 SecureKim     오후 8:44     삼성 탈레스, 세미나, HSM     No comments   


HSM 교육 후기

9시반까지 오라고 해서 새벽부터 일어나서 왔는데 10시부터 시작했습니다 ㅠ

혼자 온 사람은 나밖에 없었고.. 다들 최소 2명이상 이었습니다.

자꾸 서두에 알고계시는 분들 많을거라고 깔고가서 질문하기가 미안했지만..

철판 깔고 계속 물어보았답니다!


 그나저나 시설이 정말 최고였습니다. 세미나 + 교육 역사상 가장 좋았던

파크 하얏트 서울 !


시설 뿐만 아니라 점심으로는 코스요리가 나왔습니다.

안창살 미디움 레어 오져따리 오져따









아래는 교육 들으면서 적은거라 존칭은 생략하겠습니다.

-------------------------------------------------------------------------------------

사실 HSM에는 일반적으로 아는 것보다 더 많은 기능들이 있다.

그래서 오전에는 새로나온 기능 위주로 설명할 것이다.

12.50 릴리즈가 예정 되어 있다. 오늘은 12.40 을 기준으로 한다.


-새로운 기능 (ver 12.40)

기존에는 표준 API 개발을 했어야 했다.

OS 가 지원이 안된다던가. 클라우드에 HSM 관련 바이너리를 설치를 할 수 없다던가.


이제 !!!! RestAPI 로 HSM 과 통신 가능하다

Mutual SSL 로 상호인증 Server → nSheild Client Server (Hard-Server) → HSM

다만 제약 사항들이 아직 꽤 있다. :
Linux only,  module protected key only
cipher only :
  AES256CBC PKCS#5 ( 256 )
  RSA ( 2048 )
  ES512 ( P512 )
  HMAC sha-256 ( 256 )
  RSA SHA256 ( 2048 )

encrypt, decrypt, sign, verify only ; not generate key
POST /crypto/v1/encrypt
POST /crypto/v1/decrypt
POST /crypto/v1/sign
POST /crypto/v1/verify

GET /km/v1/keys

국내에는 아직 레퍼런스가 없다.

개발용으로 인증 안해도 API 호출 할 수 있게 가능하다.

simple 타입의 어플리케이션만 가능하다. 키 만들때 simple 타입으로 만든다.

Q. Hard-Server 에서 Mutual SSL 할 때 Private key,
클라이언트 인증서 CA가 HSM 으로 보호되나요?
A. 넵, 인증서 CA는 HSM 으로 보호(keystore - keytool 사용) 됩니다.
다만 클라이언트 인증서는 클라이언트 각자가 보호 해야 합니다.

Q. module protected key only 라는게 어떤건지?
A. 키를 사용하려면 HSM 에 스마트카드를 이용해서
한번 더 인증을 받게 하는 것(Softcard protected 등)들이 있는데 이런 키들은 제외한다는 의미.

Q. 체인을 여러개 만들어서 클라이언트별로 기능/사용가능 키 등의 권한 분리가 되는지 ?
기능이라면 어떤 애는 verify 만 되게 한다던지
클라이언트가 encrypt 시 어떤 키를 사용하는지 어떻게 알 수 있는가?
A. 권한 분류는 안된다. 그냥 클라이언트는 다 클라이언트

Q. Hard-Server 에 설치되는 API 제공 서버는 뭘로 돌아가는건지?
보안 설정은 기본적으로 어느 정도 되어 있는지?
디렉토리 리스팅 부터 시작해서 웹방화벽이라던지... CVE 패치 등등
A. 보안 설정은 해서 줄거고 CVE 패치는 필요하면 업데이트 해준다.



----------------

2차시 - 실습

키 생성 ( 로컬 )
$ generatekey simple

RSA
2048
10001
teskorea
teskoreakey
opt/nfast/kmdata/local/key_simple_teskorea


사인 요청 ( 원격 )

curl --cacert testestca.crt --cert test.crt --key test_client_key.pem --header 'Content-Type: application/json' --header 'Accept: application/json' --request POST \
-d '{"kid":"urn:uuid:어쩌고저쩌고", "alg":"RS256", "payload":"base64url 인코딩한 값", }'
'https://wsop.server:18001/crypto/v1/sign'

결과는 base64url 디코딩한 값을 사이닝한 값이다.



------------------

3차시

P11, JCE  를 표준 API 로 제공한다.

 - key blob 이란 ?

  key - ACL (Access Control List ) 가 같이 하나의 Blob 으로 되어 있다.

  ◈ 사용자 디렉토리에 저장된다.

ACL - 키 용도 ( 사인 / 암호화 등등 ), 사용 횟수 (횟수 이후 HSM 메모리에서 소거되고 다시 로드 필요), ACL 변경가능한지, ACL 볼 수 있는지, 보호 기법 ( 모듈 / 소프트카드 등)


 -Cryptoki 모델 - 모든 보안 토큰(USB 형태 포함)에서 사용되는 표준임.

각 슬롯 핸들러를 통해 토큰에 접근

어플리케이션 하나가 여러개의 토큰에 접근 가능하다.

Engine ( + Random Number Generator (with seed)) - seed 는 유저로 접근 불가.
 Object - 객체 클래스. 가장 큰 단위
 - Data : 어플리케이션이 정의한 정보를 지닌 객체
 - HW_Feature -HSM 에는 사실상 해당 사항 없음
 - Storage
   - Certificate
   - Key
     - Pub key
     - Priv Key
     - Sec key
P11 동작 흐름도 (24P)

Cryptoki application → 라이브러리, 토큰 디바이스 드라이버 로드
→ Token 이란 HSM 의 각 슬롯
→ 세션 핸들값을 받아옴
→ 세션에 로그인, 키를 생성하거나 파기, 암복호화, 서명
→ 세션 하나에는 하나의 일만 배정 가능하므로 보통 쓰레드를 20개 까지 사용한다.

SO: Security Officer

lifetime 에 따라서
Token Object 는 세션 종료 이후에도 남아있음. (인증서 발급 등)
Session Obejct 는 세션 때만 살아있음. (한번 쓰이고 버려지는 유도키 등)

접근 권한에 따라서
Public object :Token 에 대한 로그인 필요 없음
Private Object : 로그인, Pin 등 필요
RO / RW 가능.

세션 핸들 값은 새롭게 얻어와야 한다. ( 만료되며, 업데이트가 된다 )

-Cryptoki  개념
 슬롯 관리 (로그인 등 )
 객체 관리
 암호화 연산

 세션은 동시에 한가지 커맨드만 수행 가능하다.


카드 k of N - 5장 중에 3장이 있는 등 몇 장 이상 있어야 사용 가능한 개념.
확장 함수 : C_LoginBegin - C_LoginNext (다음 패스워드 입력) - C_LoginEnd

p11 사전 디파인된 값, 꼭 이 prefix 를 안붙여도 되지만 가독성 때문에 쓴다.
C_       함수  (C_Initialize, C_GetSlotList, C_Tokeninfo, C_OpenSession, C_Login 등)
CK_     데이터
CKA_  어트리뷰트 타입
CKC_  인증서 타입
CKF_  플래그 ( multithread 등 )
CKK_  키타입
CKM_ 매커니즘
CKO_ 객체 클래스 ( 큰 단위 )
CKR_  리턴값 - 디버그 환경변수를 enable 해주면 더 자세한 정보 획득 가능. (HSM기능)
CKU_ 사용자 분류

객체의 타입  (CK_ ) ----

데이터 타입
CK_TOKEN_INFO : 토큰에 대한 정보 구조체
 - label : 어플리케이션 정의 라벨 (이름).
 - ...

세션 타입
CK_SESSION_HANDLE : Cryptoki 에서 할당한 세션 ID 타입
CK_USER_TYPE : Cryptoki 사용자 분류 타입 (CKU_SO, CKU_USER, ... )

Attribute 타입
CK_ATTRIBUTE {
 CK_ATTRIVUTE_TYPE type;
 CK_VOID_PTR pValue;
 CK_ULONG ulValueLen;
}


Ex ) RSA 키를 만들기 위한 Attribute 만들기 .
각 Attribute 를 설정 해야만 제대로 키가 만들어 진다.
static CK_ATTRIBUTE rsaPublicKeyTemplate[] = {
 {CKA_CLASS, &class_public, sizeof(class_public)},
 {CKA_PRIVATE ...}
 {CKA_MODIFIABLE, ...}
 {CKA_TOKEN, ...}
 {CKA_LABEL, ...}
 {CKA_KEY_TYPE, ...}
 ...
}

나중에 코딩 할 때 만약 빠트려서 뭐가 없으면 빌드시 없다고 에러 뜨니까 걱정 노우노우

CKA_SENSITIVE : 주의. 설정이 false이면 Warning. HSM에 저장된 raw 키를 빼내 올 수 있다.
CKA_EXTRACTABLE : 다른 키로 한번 암호화 해서 wrapping 해서 빼올 수 있다.

키객체 - 인증서 각 속성들을 저장할 수 있다. 그냥 OpenSSL 연동을 다 해놔서 써도 됨.

Q. 다른 사업부로 키를 이관하는 것이 가능한가?
A. 여러가지 방법이 있고 소프트 카드를 이용해서 다른 (그러나 동일한 모델의) HSM 장비로
마이그레이션 작업을 하면 키 사용이 가능하다.

참고  :
- Optional 한 Subject 는 굳이 지정해서 null 할 필요 없이 그냥 안 넣어주면 된다.
- 키를 동일한 레이블(이름)로 생성하면 그냥 중복 생성된다.
  찾기 어려우니까 중복되지 않도록 할것.
- dynamic load 를 이용하면 동적으로 각 OS Dependency 하게 라이브러리 로딩함
- 보통 P11 에서는 goto err 등 goto 문을 많이 사용한다. 이러면 메모리가 절약 됨.
   무조건 안쓰는것도 방법이 아니다. goto 로 가서 할당했던 메모리 들을 해제.

버퍼 할당 방법

사전에 정적 배열로 할당
1. 버퍼가 얼마나 될건지 계산해서 그 이상을 할당해야 한다.
2. 먼저 작게 할당 한후 버퍼가 너무 작았으면 realloc 을 해준다.

쿼리 and 할당
1.  사인/인크립트/디크립트 을 할 때 output 을 null 로 주면된다.
     이러면 HSM 이 output 을 준다. 간단하지만 정적 할당보다 많은 메모리가 사용 됨.

strict_fips → 정책적으로 반드시 private 은 1로 설정 extractable 은  0으로 설정해야
키 생성시 에러가 안난다.


------------------------

4차시. 소스코드 보면서 알려주기

PKCS#11 - ckutil.c 참조

find_key_ex (ckutil.c)
  -label 이나 id 기준으로 찾는다.


JCE - Java Cryptographic Extension - JCEPerfcheck.java 참조

제공 라이브러리를 사용하면 자동으로 HSM 과 연동된다.

P11 보다 간결하지만, 좀 더 명확하고 디테일한 옵션을 주기는 어렵다.



일단 시스템 프로퍼티만 연동되도록 하면 된다.

먼저 KeyPairGenerator 인스턴스 등을 생성

에러가 나면 errExit 로 종료하거나 errStop 로 Thread 를 멈출 것이냐로 적절히 처리한다.


키를 저장해 두고 쓰려면 keystore 를 사용해야 한다.

→ 우리가 생각하는 그 keystore 쓰듯이 쓰면 되는데 내부적으로는 HSM 연동된다.

즉, HSM 에서 사용가능한 keyblob 이 만들어지고 keystore 에 저장된다.



Q. ncorekey 랑 jcekey랑 어떤 차이인지?

A. jce 는 자바 표준이고, 특정 매커니즘들은 지원하지 않는다. 예를들면

jce 는 sign 과 hash 가 분리되지 않아서

hash 만 보내서 HSM 에서 서명하도록 할 수가 없다.

그렇다고 바이너리 전체를 HSM에 보내는것은 무리데스

그래서 우리가 만든 ncore 로 하면 hash 를 하지 않고 서명만 하는게 가능하다.



Q. 소스코드가 없는 경우.. 바이너리를 HSM에 넣을 수 있나?

A. 불가능하다.


Q. 특정 사업부에서 다른 사업부로 키를 마이그레이션 하려고 한다.

뭔가 키에다가 설정해야 될 게 있을까?

A.디폴트 설정으로 생성하면 마이그레이션 가능이다. 




Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

2018년도 암호연구회 1차 워크샵 후기

 SecureKim     오전 10:08     No comments   



전반적인 후기


새로운 것을 시도 한다기보다 기존에 논문으로 발표되었거나 이미 존재 하는 아이디어를

구현하는 방향의 연구들이 많아서 조금 아쉬웠다.

다만 지금 한국에서 보안 관련해 대강 어떤 연구 활동들이 이루어 지고 있는지

동향 정도를 파악 할 수 있었던 건 좋았다.



-----------------------------

1차시 - FPGA 전용 암호 라이브러리 구현 및 활용 - 서울대 이재진 교수

FPGA란 프로그래머가 하드웨어 구조를 변경 가능한 보드.
SHA 를 OpenCL -> Verilog (하드웨어 설계 언어) 사용해서 구현.
Latency 줄이기, 병렬화, Frequency 높여서 더 최적화 할거다.
AES 쪽은 아직 구현을 안했다.

GPU vs FPGA
-> 성능 비교함. FPGA 도 트랜지스터가 많으면 그래픽 카드보다 성능 좋을 수 있다!

------------------------------

2차시 - 클라우드 환경에서의 암호 사용 정책 연구 - 중앙대 최명길

클라우드 보안 위협
트래픽 스니핑, 접근권한 탈취, DoS, 설계오류
+가상화 위협 - 하이퍼바이저 감염, 침입탐지 어려움 등
관리문제, 지역이 달라서 법 제도 문제도 있음

보안인증제도
암호 정책 수립
무결성 기밀성

국내 서비스 보안 기준
다른건 똑같고 서비스 공급망 관리 기준이 추가 됨.

클라우드 보안 인증제도 알고리즘 기준이 따로 있다. 각 기준은 표로 정리함.

1. 어플리케이션(암호화) -> DB
2. 어플리케이션 -> DB(암호화)
3. 어플리케이션 -> 에이전트(암호화) -> DB

- 완전 동형 암호화
데이터를 복호화 하지 않아도 연산이 가능

- 검색 가능 암호화
복호화 하지 않고 키워드 검색 가능

- 순서 유지 암호화
복호화 하지 않고도 수치데이터가 순서를 유지 가능
( 평문에 근접한 값을 얻을 수 있으면 큰 취약점이 될 수 있다. )

결국 클라우드에서 키관리를 어떻게 할거냐 ? 라는게 화두
- 서버에 저장하면 키도 같이 유출된다.

Q. 키를 암호화해서 디스크에 저장해야 한다고 했는데 그럼 키를 암호화 하는 키는 보통 어떻게 보호하는지?
A. 이게 아직 정책이 없다. 앞으로 중요한 이슈가 될 것 같다.

-------------------------------------

3차시 - 소프트웨어 자동 Exploit 생성 기술 연구 - 세종대 윤주범

사실 단기간에 하기는 어렵다

- 기존의 자동 취약점 탐지 시스템 분석
- 자동 오류 분석 요소기술 연구
- 검색기반 자동 취약점 탐지기술 연구
... 를 할 것이다.


요소기술 연구
- 정적 분석 ( 바이너리 디스어셈블 해서 unsafe함수 찾기)
- 퍼징 (찾아낸 unsafe 함수에 대해 Fuzzing )
- 기호 실행
- 동적 기호 실행

기존 연구의 문제점
시간이 오래 걸리는 단점이 있다 -> 이건 어떻게 다른가?
퍼징은 랜덤에 기반함 (찾았다가 못찾았다)

Q. 어떤 조건에 따라 들어와서 여러 로직을 거친 이후 Crash가 일어나는 입력은 어떻게 찾는지?
A. Symbolic Execution. 변수를 미지수로 표현하고 수식을 세워서 여러 로직을 탈때도 미지수로 유지.
최후에 Crash 를 일으키는 값을 수식으로 확인해서 찾음.
다만, 너무 복잡한 식은 현재 기술로는 못푼다. 그래서 Concolic Execution 쓸거다.
Concret -> Symbolic -> Concret -> ...

Taint 분석
사용자 입력값에 의해 레지스터/메모리 영역이 제어 가능한지 확인. 불가능하다면 제외.

Q. 실제 Fuzzing을 할때는 바이너리가 돌아가는 환경이 다 다를것 같고
운영체제나 특정 라이브러리를 사용한다거나 다 다를거같은데요 이 연구의 커버리지가 어떤지 궁금..

물어볼 기회가 없었다.

-------------------------------------

4차시 - 유한체 및 타원곡선 위의 이산대수 문제 분석 기법 연구 - 세종사이버대 장남수

인수분해 (RSA) / 이산대수 (DSA, ElGamal) / 타원곡선 이산대수 (ECDSA, ECDH)

4년전부터 이어지는 시리즈.. 인수분해는 알려진 공격들을 거의 구현함

이산대수
- 512bit DH 아직도 사용되는 곳이 있다. 논문도 있지만, 리얼타임으로 뚫린다.

타원곡선 이산대수
- Summation Poltnomial 공격 기법 나옴.


ECDLP 최근 동향 조사할거다.
1. Factor base selection
2. Relation collecting
3. Point decomposition
4. Linear algebra

원래는 포인트를 계속 집어넣으면서 식을 풀어나감.
그런데 실제로 이 다항식을 풀 수 있는지 의문이 있었음.

2014년에는 3개 포인트의 관계로 풀 수 있게 만들도록 개선됨 - Summation Polynomial
n이 310 보다 크면 Pollard's rho 보다 복잡도가 낮아진다.
보통은 n이 571 보다 크다. 그렇게 보안 강도가 높은 애들일 수록 더 낮아짐

이걸 구현하게 이 연구다.

--- DLP 최근 연구 동향
인수분해는 n이 주어지면 매번 풀어야함.
이산대수는 보통 하나의 도메인 파라미터를 그룹에서 공유함.
512비트 최적 파라미터 및 실험환경을 구축하겠다.

--------------------------------------------------------

5차시 - 2018 First PQC Standardization Conference - 삼성SDS 문덕재

사실 알고리즘에 대한 상세 로직은 아직 선정도 안되어서 그 부분은 잘 모름

DWave 2000Qubit - 특정 목적의 알고리즘만 동작

-General 한 양자컴퓨팅
2017.11. IBM 50 Qubit
2018.01. Intel 49 Qubit
2018.03. Google 72 Qubit

MS Azure로 Q# 이라고해서 양자컴퓨터를 시험해 볼 수 있다.
이미 C, C++, Java 등으로 구현 가능

기존에는 결정된 정보만 전달 가능.
양자컴퓨터는 여러개의 상태를 저장할 수 있고, 한번만 측정 가능한 특징을 가진다.
예를들어 미로찾기에서 모든 상태를 다 한번에 저장했다가 미로를 빠져나오는 부분만 측정 하면 된다.

양자컴퓨터로는 1024 비트의 RSA가 실시간으로 깨진다.
현재는 O((log N)^3)
O(루트^3 N) 까지 나옴
RSA ECC 다 깨진다
-> GDPR 도 관련 있다. 개인정보 암호화가 깨지면 GDPR 도 같이 문제된다...

대비할 시간이 얼마나 필요한가?
->(eprint.iacr.org/2015/1075)
x years - 암호화 된것이 얼마나 보호되길 원하는지에 대한 시간
y years - 복호화 했다가 PQC 로 다시 암호화해서 저장하는데 걸리는 시간
z years - 양자 컴퓨터가 나와서 solver가 돌아가는 시간

x + y > z 이면 risk 하지 않다.
2015.04 PQC 공모를 통한 표준화 진행

MS에서 10년 내 Personal 양자 컴퓨터가 나온다는 확신이 있다.

알고리즘 고속화보다 키 Generate 고속화가 더 시급하다.
암호화 / 서명 / 키공유
TLS, SSH, IPSEC 등에 녹아 들 수 있어야 한다.

Signature, Encryptions, Key-establishment

PQC 알고리즘은 장단점이 너무나 극명하여 갈길이 멀다.
Code based - McEliece - 빠른 암복호화 / 큰 키 사이즈 (기가단위)
Hash based - SPHINCS+ - 매우 안전한 증명 / 큰 서명 사이즈 (메가단위)
Lattice based - NTRU, GGH - 다양한 환경 및 고속 구현 가능 / param 설정 표준(이정도면 괜찮다) 없음
Multivariate - HFEc- 작은 서명 크기, 빠른계산 / 큰 키 사이즈, 나오는 족족 깨짐
Isogeny - 정말 작은 키 사이즈 및 OpenSSL 등등이 다 있다 / 속도가 느림

표준 로드맵 - 1St NIST Standarication Conference
1. PQC 알고리즘 제안 마감 - 82개
2. 설명회
3. 20개쯤으로 줄이기
4. 최종 후보 선정

PQCrypto 에 들어가보면 히스토리 전부가 나와있다.

Nist 표준에 제안되는 Feature - 가 서명 . 암호화 . 알고리즘이 되어아한다.
82개가 공모되었는데 4개월만에 벌써 엄청나게 깨졌다,
Lattice 기반은 잘 안깨짐 -> 1년 이상 연구한 사람 이외에는 깨기 어렵다.
Standard / Ring / Module 문제가 있는데 Module 문제가 가장 안정성이 높다고 평가됨.

EMBLEM(한국), LAC, HILA, LIMA 알고리즘이 관심이 많았다.
대부분 유럽에서 공동연구 알고리즘을 내는데,
우리 나라 알고리즘이 살아남을 수도 있겠다 싶었다.

----------------------------------------

6차시 - 거래 추적 불가 암호화폐 취약성 연구 - 한양대 윤종원

일반적으로는 블록체인에 모두 남게된다.

각각의 트랜잭션들에 In Out 이 모두 기록되는데, 추적 불가능한 암호화폐는
거래 내역을 은닉한다.

DASH, Monero, Zcash, Verge, PIVX. 추적가능한지 확인해 보았다.

1. Denomination
A가 100Dash 를 B에게 보낸다 -> 10^ 단위로 나누어 잘게 쪼갠다.

2. Mixing
보내기 전에 일정한 단위 금액으로 나눠진 코인을 다른 사용자의 코인과 섞은 뒤 보낸다.
2 ~ 8 회 반복한다 (다른 마스터 노드에게 보냄)

Mixing 에 관여하는 노드는 마스터노드이며, 1000Dash 이상 보유한 경우.

다만 마스터노드는 딱 해당 단위 Dash 만 처리 할 수 있다. 0.01 / 0.1 / 1 / 10 / 100 Dash 등

임의의 주소로 들어와서 임의의 주소로 나가는 것들을 확인 가능.

수신자 입장에서는 수신된 주소는 하나이고 인풋은 여러개임.
그래서 이게 많아지면 너무 경우의 수가 많아진다
그래서 입력의 개수가 하나이고 거기서부터 파생되니까 Denomination 트랜잭션도 확인.

1. output 총 합이 Input 보다 작은 애들은 제거.
2. Denomination 되는 애들을 확인

Monero
가장 최근 것이 실제 트랜잭션이다

ZCash
T-addr, Z-addr 조합. 3가지 조합이 나온다. T - Z, Z - T, Z - Z
Z-addr - Z-addr 조합에서만 Private 인데 사실 전체 거래량의 0.4 % 밖에 안된다.


Q. 마스터노드가 마스터 노드에게 Dash를 받았을 때, 디노미네이션 이후
최종적으로 어떤 사람에게 보내야 한다는걸 어떻게 알 수 있는건지 ?
A. 송신자가 코인을 보낼 때 최초에 정해진다.
사실 마스터노드가 다른 마스터노드로 보낼 때는 전달만 할 뿐이다.

Q. 2명이 동일 시각에 동일한 금액을 2명에게 보낼때. 추적가능한지?
왜냐면 실제 대시네트워크에서는 이런일이 있을 수 있음.
A. 사실 이런 경우는 알 수 없다. 낮은 확률로 이 사람이 받았을 것 같다 정도를 아 수준이다.

-----------------------------------------------

7차시 - 지문인식 기반 보안 체계 취약점 분석 - 인하대 최학남

실제 기기에서는 지문과 갤러리에 있는 지문이 동일한가를 판단한다.
1. 일단 지문을 많이 만들어 본다
2. 특징점을 잡아서 지문을 만들어 본다

지문 생성시 파라미터는 다음과 같다.
Shape ( 모양 ) , Direction map ( 방향성 ), Density ( 밀도 )
이런 파라미터를 모아서 Master Fingerprint 를 만든다.
Master Fingerprint 도 Noise, 압력 등에 따라 또 이미지가 다르다.

기존 지문 생성 알고리즘들 소개 및 비교

이 연구의 목표
1. 우리는 일단 지문을 많이 만들어서 우회를 해보겠다.
2. 또 특징점을 안다고 가정하고, 만들어서 우회를 해보겠다.

-----------------------------------------

8차시 - 상용 패스워드 관리 프로그램 취약점 분석 - 서강대 소재우

연구 순서
1. 패스워드 저장소 취약점 분석(로컬)
2. 논리적 취약점 분석 (메모리 등)
3. 웹 취약점 분석 (CSRF/XSS/Phishing)

패스워드가 너무 복잡하고 많으니 Password Manager 가 등장하게 됨.

브라우저 기반 (built-in)
웹 기반
로컬 기반
하드웨어 기반
기업용 - 서버기반

이러한 매니저들에는 소프트웨어 취약점이 존재하고있고 국내에서는 연구가 미흡하여 추가 연구하려 한다.
저장소의 위치를 찾아내서 알고리즘을 알아내고 디크립트 해본다.

CryptProtectData 라는 API 를 사용하고 있음.
CryptUnprotectData 를 사용하면 된다.


User DataDefault
AppDataLocal***User DataDefaultdatabases
저 장소의 권한이 어떻게 되는지

Q. 몇년전에 G사 모바일 쪽 PM을 열어봤었는데 거긴 평문이었다.
입장을 찾아보니 ADB조차 그 파일에 접근할 수 없으므로 정책을 그렇게 세웠다. 라고 하던데
이렇게 권한으로 보호하고 있는 경우라도 패스워드를 풀 수 없게 해야 된다는 것인지
A. 사실 윈도우 같은 경우에 자리를 비울때 윈도우 락을 걸어야 안전한데 그런 경우가 잘 없다.
그렇기 때문에 보호 해야 한다고 생각한다.

Q. 그러면 반대로... 윈도우에서 저걸 보호하려면 어떻게 해야 하나?
A. 사실 프리웨어를 쓰는게 좋다. 계속 패치가 되니까. 그리고 근본적인 해결책은 없다고 생각한다.
이런식으로 암호를 저장하지 말아야 한다.

----------------------------------------

9차시 - 암호 라이브러리에 대한 GPU 캐시 부채널 공격 분석 기술 연구 - 광운대 신영주

가상머신
캐시는 CPU 와 메모리간 속도차를 줄이기 위한 것. 메모리 대비 10~100배 고속.
Cash hit과 Cash miss 이 났을때 데이터를 가져오는 시간이 다르다.
이 시간차를 이용해서 부채널 공격을 시도한다.

L3 캐시에서 부채널이 발생
가상 머신들 간 L1, L2 는 각 코어에 배타적으로 할당되지만
L3 는 CPU간 공유되기 때문이다.

2016년에는 AWS에서 불특정 다수의 EC2 인스턴스를 대상으로 RSA 키 공격이 가능했다.

1. Flush + Reload
Victim 과 공격자가 캐시의 메모리 라인을 공유해서 발생하는 간섭 현상을 관측
한 라인은 64byte 크기이다.
공격 선행 조건 - 프로세스 혹은 가상 머신 간 메모리 공유 / 캐시 제어 명령어가 필요하다

Content-aware - 공유라이브러리 (일반적)
Content-based (memory deduplication) - VMWare에서 사용
하이퍼바이저가 메모리 페이지를 다 관리하고있고, 이걸 VMWare 들이 나누어 사용한다.
이때 동일한 페이지를 사용해 충돌하는 경우가 발생하게 된다. 이때 하이퍼바이저가 주기적으로 스캔해서
발견하면 하나의 페이지로 합친다. 그럼 VMWare들이 하나의 메모리 페이지를 공유하게된다.
1. 공격자는 희생자가 해당 메모리라인을 읽었는지 확인하려함
Attacker 는 flush를 통해 L3 에서 메인 메모리로 내림
2. Victim 이 access 했다면 cash hit 아니라면 cash miss.
캐시에 올라가있으면 캐시를 가져온다 -> Cash hit (희생자가 Access 했다)
캐시에 올라가있지 않으면 메모리에서 가져온다 -> Cash miss ( 희생자가 Access 하지 않았다.)

GnuPG 에서 RSA 복호화를 할때, square 연산 / multiply 연산 / moduler 연산을 함.

GnuPG 를 리버싱해서 실행 코드의 메모리 코드값을 확인하고 probing
복호 연산을 하고있을때 비트값의 변경이 있는지 확인 가능.

2. Prime + Probe
캐시집합단위의 간섭 현상을 관측한다. 메모리 공유 필요가 없다.
이건 이번 연구와 관련없어서 따로 설명 안함

-> 그래서 이제 이런 툴 구현을 해보려고 한다.
구현해서 2차 워크샵때 다시 발표하겠습니다.'


Q. 공격자가 Sync 는 어떻게 맞추는지? 실제로는 서버가 언제 복호화 로직을 실행할지 시점이 애매할 수 있을 것 같다.
A. 여기서 타겟으로 잡고 있는 가상화 환경의 경우 대부분 서버로 가정되기 때문에, 공격자가 Request 를 날려서
그때부터 Probing 을 하면 될 것이라고 생각한다.

-------------------------------

1년에 3번의 워크샵을 하는데, 8월 / 11월에 또 한다. 2차 3차.
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

2018년 5월 8일 화요일

[Batch] dot 이 여러개 들어간 파일 이름 하위 폴더까지 일괄 변경

 SecureKim     오전 1:15     일괄 변경, 파일명, bat, Batch, for, move, ren     No comments   



사실 간단한건데 batch 문법을 모르거나 까먹으면 한참 헤메게 되므로 올립니다...


.9.png 같은 파일을 하위 폴더까지 찾아

일괄적으로 .png 로 변경하고 싶을 때

아래 스크립트를 이용하면 됩니다.


@echo off
for /f "tokens=*" %%a in ('dir /s /b') do (
set b=%%a
setlocal EnableDelayedExpansion
if "!b:~-6,6!" EQU ".9.png" (
echo !b! -------- !b:~0,-5!png
move !b! !b:~0,-5!png
)
)

그냥 쓰면 되는데 미리 알아두면 좋은 사항은 다음과 같습니다.

ㆍfor 문법 그리고 변수 접근시 %% 를 사용한다는 것을 알아두어야 합니다.

ㆍren 이 먼저 떠오르는데, 대상 파일로 드라이브를 지정할 수 없고
*.*.* 이런 형태는 잘 지원하지 않으므로 애초에 move 를 쓰는게 낫습니다.

ㆍif 들어가기 전에 setlocal EnableDelayedExpansion 와 ! 접근자를 사용해줘야 합니다.
batch 에서 이런 부분은 모르면 한참 헤메기 때문에 매우 짜증이 나게 됩니다...

ㆍset의 :~ 사용법도 잘 알아야 겠죠
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

2018년 1월 24일 수요일

Node.js 에서 RSA 로 암복호화 하기

 SecureKim     오전 12:34     암복호화, decrypt, Encrypt, Node.js, RSA, Security     3 comments   


Node.js 의 crypto 모듈은 기본적으로 제공되므로, npm 으로 설치할 필요가 없습니다.

crypto 기본 모듈을 사용해 RSA 의 키로 암복호화 하는 방법을 알아 봅시다.

일단 그 전에 OpenSSL로 RSA Private Key, Public Key 를 생성합니다.


C:\Users\Public>openssl genrsa -out private.key 2048

Generating RSA private key, 2048 bit long modulus
.................................................................................................................................+++
.........+++
unable to write 'random state'
e is 65537 (0x10001)


예전 블로그의 AES 관련 글 을 보시면 아시다시피,

Private key 로 Public key 를 Generate 할 수 있습니다.

C:\Users\Public>openssl rsa -in private.key -out public.key -pubout

그런데 단순히 이렇게 하시면, 결과가 PKCS#8 표준으로 나옵니다.

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuErwCGWyq3nIASTKhgiH
GAaURZ9rs5EBR9L1YUJh1ftYgQSt0gUzab6hyW/upgM4Z4Mu6pA+KZCHncKc4SHJ
XdJvYnj1L6/RRinXQp+R3MmGypoB/r1ckM1aEt75/I0m7Dlatj58f56Z21yHsJNb
tf1LAD981a3kR6kaIb7Uc5bsUDwObF2r5xAenQDtaZoWgaErHWwiqzJJQebcAVVq
lq2/+f1kzRVqHsasosXOD6hrDz9oC2SvBKWVrmOPF4D+mwwaChEKAhFDvCKj5NYw
prmoOXWK6t5WroYvsVo5Sa039DiCPXMsug9MidhQLB7SpW7Bi+xeuwvObWppgGZ8
FQIDAQAB
-----END PUBLIC KEY-----

PKCS#8 표준의 ASN.1 구조를 보면 다음과 같습니다.
PublicKeyInfo ::= SEQUENCE {
  algorithm       AlgorithmIdentifier,
  PublicKey       BIT STRING
}

AlgorithmIdentifier ::= SEQUENCE {
  algorithm       OBJECT IDENTIFIER,
  parameters      ANY DEFINED BY algorithm OPTIONAL
}

우리는 PKCS#1 을 사용할 것이므로 아래와 같이 변환합니다.

C:\Users\Public>openssl rsa -pubin -in public.key -RSAPublicKey_out


-----BEGIN RSA PUBLIC KEY-----

MIIBCgKCAQEAuErwCGWyq3nIASTKhgiHGAaURZ9rs5EBR9L1YUJh1ftYgQSt0gUz
ab6hyW/upgM4Z4Mu6pA+KZCHncKc4SHJXdJvYnj1L6/RRinXQp+R3MmGypoB/r1c
kM1aEt75/I0m7Dlatj58f56Z21yHsJNbtf1LAD981a3kR6kaIb7Uc5bsUDwObF2r
5xAenQDtaZoWgaErHWwiqzJJQebcAVVqlq2/+f1kzRVqHsasosXOD6hrDz9oC2Sv
BKWVrmOPF4D+mwwaChEKAhFDvCKj5NYwprmoOXWK6t5WroYvsVo5Sa039DiCPXMs
ug9MidhQLB7SpW7Bi+xeuwvObWppgGZ8FQIDAQAB

-----END RSA PUBLIC KEY-----



PKCS#1 의 ASN.1 구조는 다음과 같습니다.
RSAPublicKey ::= SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
}

(참고로 반대로 ( PKCS#1 -> PKCS#8 ) 변환하는 하는 방법은 아래와 같습니다.)
openssl rsa -RSAPublicKey_in -in -pubout

이제 예제를 볼까요?



RSA encyrpt & decrypt in node.js


var crypto = require('crypto');

var PRIVKEY = '-----BEGIN RSA PRIVATE KEY-----\n'+
'MIIEowIBAAKCAQEAuErwCGWyq3nIASTKhgiHGAaURZ9rs5EBR9L1YUJh1ftYgQSt\n'+
'0gUzab6hyW/upgM4Z4Mu6pA+KZCHncKc4SHJXdJvYnj1L6/RRinXQp+R3MmGypoB\n'+
'/r1ckM1aEt75/I0m7Dlatj58f56Z21yHsJNbtf1LAD981a3kR6kaIb7Uc5bsUDwO\n'+
'bF2r5xAenQDtaZoWgaErHWwiqzJJQebcAVVqlq2/+f1kzRVqHsasosXOD6hrDz9o\n'+
'C2SvBKWVrmOPF4D+mwwaChEKAhFDvCKj5NYwprmoOXWK6t5WroYvsVo5Sa039DiC\n'+
'PXMsug9MidhQLB7SpW7Bi+xeuwvObWppgGZ8FQIDAQABAoIBAQCPOcYkcI0UETgs\n'+
'E2DGHBiJxoszNLuqOVaKcFw9sy5/87ALzQwdvecAFqR7/d617KjIYb5zk5iMCwQq\n'+
'ylXL7csmfGYOXL0Iy5ZT9i6SW5srwP9ds6U7SgWHj+Ch6+LSsQx/5+8k1ZlCQYuH\n'+
'XPkjdNKAtJK2ZaDqHBPe0YA6m6lXDrEOJl6xrlUWCZS02XPIXFaB+qTBG2UqWCUK\n'+
'KzVa9qIqWf3bVGJCLc70u5UiuvCC+V8VtJ964AEnj90qZy1tRhEc2X8bbWmhL3yB\n'+
'3SLWH4ZvJyEDQe/yycx9rO6CymDj3c378IyWORYt1y6mKRmltr2NJ1Ecbl9xaFrc\n'+
'JeVO8wDdAoGBAOUjZzuaVppccEIiBbLS0NksSeD4tfjlUPFqVU1obZcbkDugK1Id\n'+
'og+W5yVy2NqgeEi4nQ9Ogi485cWbCzTZM52d9zuFe/60hBFPU8jWxafW0OW2o6ci\n'+
'F1vtzWEF2EO7omUoiGu6mOI4yRcUMwXiw1cCWr2NYpASQ39QuxwXKgg7AoGBAM3l\n'+
'sC7nxqDusq+J9CI6V+oNb2v7KgapQmrdXNB5l6Mk2Dl/uNfuX5cDceMQlO5B/ObT\n'+
'44kgsBR3tO6y7PQLDClt5ZPrVJZ16+cCj41UDDgZDD0vDaU24K/qSVrsOH4gNgeM\n'+
'CcsInzX/l1bm+RAhE0pHuPHBZFuLi8brV/wZCpfvAoGAQu4XbmKDn20W4UpczcIk\n'+
'fPshzVP4m24oOYwsxIKXWEcV10TOwpqjRth2RgsI6rtqxxsdzWXKQsVI/HJwUIyN\n'+
'NiH5IGq6MEj8Nq4sNAMAEyl9NUwm+1/K4PBSSF/Trt0070Vqq8UCeTnLCzG8QaDe\n'+
'HCE07h9JRfn/u0WSkf72KRcCgYAUTGmjJix53y50idgsq63RIEP01E0fXP50RKCK\n'+
'2QHvDonWmVXiy9hWrftDVHYqSw0gwJD1CujxC6AlzDP6F0C6sN/qRlAPiU6ZdrIq\n'+
'T7foq+d9/K6OtCtQjHtw4ErtfEV3VwH8Jzxy+WC1K44wXeJl904vX06Ci+5azQbe\n'+
'jqVxtwKBgBnxVKFQCmuDjOZrf7V0jB/mf4ir9npqvHdJMHE/Et70lOaUbhat6i+Y\n'+
'PPtJewynfF4zp+HD6jOlj4RhbCncMNdaWAyDYOucYOJOpMr5mIYJHdCOVQ0aSRD7\n'+
'/dZEOGblrch6VXOEvC++yaToNhjkeTP63IH4K6uqa9btelz3Df5Y\n'+
'-----END RSA PRIVATE KEY-----\n';

var PUBKEY = '-----BEGIN RSA PUBLIC KEY-----\n'+
'MIIBCgKCAQEAuErwCGWyq3nIASTKhgiHGAaURZ9rs5EBR9L1YUJh1ftYgQSt0gUz\n'+
'ab6hyW/upgM4Z4Mu6pA+KZCHncKc4SHJXdJvYnj1L6/RRinXQp+R3MmGypoB/r1c\n'+
'kM1aEt75/I0m7Dlatj58f56Z21yHsJNbtf1LAD981a3kR6kaIb7Uc5bsUDwObF2r\n'+
'5xAenQDtaZoWgaErHWwiqzJJQebcAVVqlq2/+f1kzRVqHsasosXOD6hrDz9oC2Sv\n'+
'BKWVrmOPF4D+mwwaChEKAhFDvCKj5NYwprmoOXWK6t5WroYvsVo5Sa039DiCPXMs\n'+
'ug9MidhQLB7SpW7Bi+xeuwvObWppgGZ8FQIDAQAB\n'+
'-----END RSA PUBLIC KEY-----\n';

// RSA PRIVATE ENCRYPT -> PUBLIC DECRYPT //
 myMSG = "[ORIGINAL] I'm securekim !!!";
 
function privENC_pubDEC(originMSG){
 encmsg = crypto.privateEncrypt(PRIVKEY, Buffer.from(originMSG, 'utf8') ).toString('base64');
 msg = crypto.publicDecrypt(PUBKEY, Buffer.from(encmsg, 'base64'));
 console.log("Encrypted with private key : "+encmsg);
 console.log(msg.toString());
}

function pubENC_privDEC(originMSG){
 encmsg = crypto.publicEncrypt(PUBKEY, Buffer.from(originMSG, 'utf8') ).toString('base64');
 msg = crypto.privateDecrypt(PRIVKEY, Buffer.from(encmsg, 'base64'));
 console.log("\nEncrypted with public key : "+encmsg);
 console.log(msg.toString());
}

privENC_pubDEC(myMSG);
pubENC_privDEC(myMSG);



  • 결과 :


Encrypted with private key : Q9Tz2LRlv91Rk2ScR/Wjv77ouDsiWyefVIKlssIYHBJihZeQ0IDH+rUCMG0aBhSDNT92zZjAmPF5Pah9xejqYsfCfDslmNp+FXvmfoA02uviW6b4A6e90U3atyU1PIZHtp4nDtIAYCvY78xzEyZ5oqwhbDcKuIcs4Uo4dtXNmo6N9/+Rxckf0ByCyRAUv86x1a6SYzgqyGthaDAnIUxFAXsJpAkrAOTeBy9PKx785DEXYDBOzgsFcZRHwMuFNFlMTYfQtW/rwPL0cSA6ud3Ew0Qsv4wY73ty46s2kYezSo6YjrHkYDotlhXLK5rqY+bBtU/SAufvhj/BDxYEDe9scQ==
[ORIGINAL] I'm securekim !!!

Encrypted with public key : CEhDVj/6KquMN5QRi69okZXz6gVjHKQGOm1C1CvBExRTQrKN8sMMT1wqTQpRdVzu+YUlidgCmj+v+5bgiSMl1Ul38VUHT9rL42fwT226RYfhlMvRn2umddboyHh0TMPwWqI6aQ/36DQqmuXN34Rk2It2qs5gERZWTJgRdQ1mYrrz7nOA5nnu/vZyOmk4PjYww9QediUF+J9pxOAlYsIT+AdOXVvdKeB6M5esGZWwQ3trZvklG0KmZSNUQ6HyvQ/+MorsKDMOZxpRcBxTB+3DzzUb+UtvBSlsUNYfnMAYlEeB7M4AzgIJpZ8jfYOecp9DSx6eTzk919YVCyUU3GL2oQ==

[ORIGINAL] I'm securekim !!!


일반적으로 각 함수가 사용되는 용도는 다음과 같습니다.

ㆍprivENC_pubDEC

   - Signature Verify
    예를 들어 상호 인증시 클라이언트는 이때까지 주고받은 내용을 Hash 한 다음
    Private key 로 암호화해 Signature 를 생성해 서버로 전달합니다.
    서버는 이때까지 주고받은 내용을 Hash 한 값과,
    클라이언트가 보내준 인증서의 Public key로 Signature 를 복호화 한 값을 비교하여
    동일한지 판단 합니다.

ㆍpubENC_privDEC

    - AES KEY nego
     클라이언트가 AES Key 를 서버의 Public key 로 암호화해서
     서버에게 전달 해 주면 서버에서는 복호화 합니다.
     이렇게 하여 클라이언트와 서버는 AES Key 를 나눠갖게 되고,
     이후 통신은 AES KEY로 하게 됩니다.

이후 통신을 AES KEY 로 암호화 하는 이유는 RSA 암호화 방식은 AES 에 비해 너무 느리기 때문입니다.

그리고 메시지의 길이가 긴 경우 아래와 같이 RSA 로 암호화가 되지 않습니다.

Error: error:0406C06E:rsa routines:RSA_padding_add_PKCS1_type_1:data too large for key size

다음 포스팅에서는 Node.js 에서 crypto 모듈을 사용해 AES 암호화를 해보겠습니다.

Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

2017년 10월 18일 수요일

Wifi WPA2 "KRACK" 공격 상세 분석

 SecureKim     오후 11:55     분석, 취약점, KRACK, MITM, Security, TKIP, wifi, WPA-2     No comments   


핵심 요약


일단 시간이 없는 사람들을 위해 KRACK 공격의 핵심을 요약하면 다음과 같다.

ㆍ키가 재사용 되면 패킷이 해독될 위험이 있다.
ㆍKRACK은 키를 재사용 하도록 할 수 있다.

내용이 쉽지는 않기 때문에 왜 재사용 되면 안되는지

어떻게 재사용 하도록 하는지는 아래에서 자세히 설명한다.



선행 학습 - 요약


일단 공격을 이해하기 전에 선행 학습 해야 할 내용이 있는데,

참고 자료들도 적은 양은 아니므로 중요 내용만 요약하면 다음과 같다.

ㆍWPA 는 EAPOL 포맷의 4-Way Handshake를 사용하며,
한번 사용된 PTK는 다시 사용되지 않아야 한다.

ㆍWPA에서 동일한 키로 자꾸 암호화 하면 해독 될 가능성이 높다.
특히 Context 內 영어 등 자연어가 있으면 거의 된다고 봐야 함.

ㆍJammer와 RogueAP, 다양한 채널을 이용하면 Wifi도 MitM 할 수 있다.

ㆍPMK 는 Pre-shared password (와이파이 패스워드)로 부터 나온다.

ㆍPTK 는 PMK, ANonce, SNonce, MAC( AP, Client) 주소로 부터 나온다.
실제로 사용되는 것은 PTK 로 부터 나온 KCK, KEK, TEK, TK( CCMP ) 등 이지만,
아래부터는 PTK로 작성한다.

  • KCK is used to construct MAC in EAPOL packets 2,3 and 4.
  • KEK is used to encrypt some data sent to client(for example GTK).
  • TEK is used for encrypting traffic between client and AP, later during session.

KRACK 내용 분석


일단 두가지를 먼저 짚고 넘어가자.

1. wpa_supplicant 2.4, 2.5 버전에는 특별한 버그가 있다.

재전송된 Msg3 을 받았을 때, TK 를 0으로 채워서 인스톨 한다는 점이다.

이것은 당시에는 심각하게 받아들여지지 않았는데,

Side Effect 를 일으킬 수 있으므로 분리 패치가 필요한 부분이다.


2. iOS 와 Window 도 안전하지 않다.

Msg3 재전송을 허용하지 않기 때문에 ( 근데 이거 802.11 표준 위반이다 )

Key reinstallation Attack 에는 취약하지 않지만, Group Key Handshake 공격에는 취약하다.


자 이제 논문의 그림을 보면서 하나씩 이해하려고 노력해 보자.



PHASE 1. 공격자는 쭉 메시지를 보다가 Msg4 를 가로채고 보내지 않는다. 
            (이걸 대체 어떻게 한건지 디테일은 최하단 내용 참조)

PHASE 2. 클라이언트는 Msg4 를 보낸 직후 PTK & GTK 를 설치하고, 
            설치한 PTK로 데이터를 암호화해서 보낸다.

PHASE 3. AP는 Msg4 가 오지 않으므로 클라이언트가 Msg3 를 못 받은걸로 생각하고, 
             다시 MSG4 를 설치했던 PTK로 암호화해서 보낸다. 공격자는 이걸 그대로 전달한다.
             클라이언트는 Msg3를 받고 nonce 와 replay 카운터를 초기화 한다.

PHASE 4. AP 사이드에 연결을 성립시켜서 PTK 설치하게 한다.
             생각해보면 AP는 Msg4를 받지 않아 아직 PTK 가 설치 되어 있지 않기 때문에, 
             클라이언트가 보낸 암호화된 Msg4 를 reject 할 것이다.
             그러나 802.11 표준을 유심히 살펴보면 마지막 counter 뿐만 아니라 
             4-way handshake 에 사용된 모든 replay counter 를 받아들이도록 되어 있어서 문제 없다.
             즉, 어떤 AP는 r+1을 받아들이고 어떤 AP는 이전에 암호화된 Msg4 를 받아들임
       

PHASE 5. 클라이언트가 데이터를 다시 동일한 Nonce와 PTK로 암호화해서 보낸다.


결국 요약하면 


WPA는 일반적으로 키를 자주 Refresh 하므로

복호화 하기 매우 어렵다.

하지만 쓰던 키를 재사용 하도록 공격 해서 데이터를 모은 다음,

데이터가 쌓이면 결국 복호화 할 수 있다 라는 말이 된다.


위험도

4-Way Handshake 가 나온 이래 14년간 누구도 생각지 못한 엄청난 공격이다.

그래서 와이파이 세상이 망한 것 처럼 화제가 되고 있지만

글쎄, 전통적인 WPA Crack 에 쉽게 깨지는 패스워드를 사용하고 있는 AP가

이 세상에 얼마나 많은데

굳이 AP 와 Jammer 를 사고 펌웨어를 수정해서 이 공격을 할까?

게다가 HTTPS 를 깨는 것이 아니라서,

주의심이 깊은 사용자라면 당하지 않을 수도 있다고 생각한다.



복호화

사실상 암호화는 PTK 로 직접 하는 것이 아니라, PTK 로 Derive 된 임시키를 
OTP (One Time Pad)로 사용하게 된다.
참고로 이 임시키는 매 패킷마다 시퀀스 번호를 참조하여 derive 되는데...

ㆍ가장 궁금해지는 부분이다. 키를 알지 못하는 상태에서,
단지 키를 재사용한다는 이유만으로 어떻게 복호화가 가능한가?

아래 그림을 참고해 보면 이해가 쉽다.



KRACK 의 주장은, 거의 모든 패킷에 항상 영어 단어 등이 있을 것이므로
Message 1, 2 를 갖고 있을 때 분리가 가능하다는 것이다.

Crip-drag 공격 참조
http://travisdazell.blogspot.kr/2012/11/many-time-pad-attack-crib-drag.html

Two Time Pad를 통해 자연어를 자동으로 해독하는 방안에 대해서는
아래 참고 논문을 참조하면 되겠다.
https://crypto.stackexchange.com/questions/2249/how-does-one-attack-a-two-time-pad-i-e-one-time-pad-with-key-reuse/2250#2250

디테일


ㆍ논문에서는 다양한 공격들과 디테일을 더 다룬다. 논문을 직접 보는게 더 좋다.

ㆍTKIP 나 GCMP 를 쓰는 경우 복호화 뿐만 아니라 패킷을 Inject 할 수도 있고,

GCMP의 경우 Key 를 복구해 낼 수도 있다. (https://www.krackattacks.com/)


ㆍ이 공격을 성공 시키려면 PMK 를 모르는 상태에서 Wifi 를 MitM 해야하고

그러기 위해서는 Channel Based MitM 을 먼저 시도해야 한다.
(https://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014.pdf)

이때 Rogue AP 2개와 Jammer 가 필요하며 Latency 가 두배 가까이 늘어나게 된다.

위 논문에 의하면 MitM시 Latency는 3.82±10.4 ms. -> 7.45±12.9 ms

100MB 파일 다운로드 속도는  18.6 Mbps -> 8 Mbps 로 변했다고 한다.

즉, 평소보다 다운로드 속도가 많이 느리다면 

공격의 징후로 볼 수도 있다.



참고 자료



WPA 설명 자료 (IEEE802.11i)

http://ieee802.org/16/liaison/docs/80211-05_0123r1.pdf

OTP가 두번 사용될 경우 자연어 자동 해독 방법

https://crypto.stackexchange.com/questions/2249/how-does-one-attack-a-two-time-pad-i-e-one-time-pad-with-key-reuse/2250#2250

각종 용어 설명은 아래 참조
http://etutorials.org/Networking/Wireless+lan+security/Chapter+8.+WLAN+Encryption+and+Data+Integrity+Protocols/Key+Management/

4 way handshake 이해하기 좋은 그림
https://netmanias.com/ko/?m=view&id=blog&no=5376


PMK 를 모르는 상태에서 Wifi MitM 을 어떻게 하는건지?



https://people.cs.kuleuven.be/~mathy.vanhoef/papers/acsac2014.pdf

위 논문은 좀 더 자세하게 다루고 싶은 내용이라 요약하자면, 

ㆍ4 way handshake 때문에 MitM 위치 잡는게 사실상 어렵다. 
세션키가 MAC주소에 기반하기 때문에 AP와 동일한 MAC 주소를 가져야 하는데, 
AP와 클라이언트가 통신 해야 하기 때문에 불가능했다.

ㆍ그래서 두개의 AP를 만들어 하나는 실제 AP와 같은 채널에, 
다른 하나는 AP와 다른 채널에 둔다.
다른 채널에 있더라도 물리적으로 가깝게 있기 때문에 서로 프레임을 수신 할 수 있어서 
무한 루프에 빠질 수 있는데 이를 막기 위해 최근 전달된 프레임을 
시퀀스 번호로 추적해 새 프레임만 전달하도록 했다.

ㆍ이 Rouge AP를 102.4 ms 마다 뿌림. 
다만, 뿌린다고 해서 클라이언트가 바로 채널을 변경하는 것이 아니다.

ㆍ비컨을 선택적 Jamming 했더니 반드시 몇 프레임은 손실되었다. 
특히 authentication message 는 34바이트밖에 안되서 
거의 선택적 Jamming 을 할 수 없었고 클라이언트를 Rogue AP에 붙일 수 없다.
그래서 실제 AP를 지속적으로 Jamming 해서 클라이언트가 Rogue AP 에 붙게 했다.

ㆍ다른 채널에 AP를 복제하는 것은 간단하지만, 
실제 AP 채널에 있는 장치는 모든 클라이언트 MAC 주소를 Listen 하고 있다가 보내야 하므로,
Attacker 측 드라이버 펌웨어를 수정해서 Sequence Number 를 덮어쓰는걸 방지했다.

이렇게 하면 와이파이 패스워드를 몰라도 MitM 위치에서 선택적으로 패킷을 버리거나 다시 보내거나 할 수 있다.

물론 그렇다고 해도 2014년 당시 이 논문으로는 패킷을 decrypt 할 수 없었다. 
(하지만 3년후 이 아저씨는 결국 대박을 치게 된다)


Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

2017년 10월 12일 목요일

Node.js 에서 Redis Session 사용하기

 SecureKim     오후 3:23     cookie, Node.js, Redis, session     No comments   


Node.js 에서 Redis Session을 사용하는 예제


Node.js 에서 Redis Session을 사용하는 단순한 예제.

Use Redis Session in node.js


var express   = require('express');
var router          = express.Router();
var path   = require('path');
var favicon   = require('serve-favicon');
var cookieParser  = require('cookie-parser');
var bodyParser  = require('body-parser');
var http    = require('http');
var expressSession  = require('express-session');
var fs     = require('fs');
var RedisStore      = require('connect-redis')(expressSession);
var redis           = require('redis');
var app = express();
//http////////////////////////////////
var httpServer=http.createServer(app);
httpServer.listen(80, function(){
 console.log("http server listening on port " + 80);
});
////////////////////////////////
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));
app.use(cookieParser());

var redisConfig = {
    "host": "localhost",
    "port": 6379,
    "prefix": "session:",
    "db": 0,
    "client": redis.createClient(6379,"localhost")
}
const session = expressSession({
    secret : new Date().getMilliseconds()+"brokim",
    resave : false,
    store  : new RedisStore(redisConfig),
    saveUninitialized:true,
    cookie : {
        maxAge : 1000 * 60 * 3
    }
});
app.use(session);
app.use(favicon(path.join(__dirname, 'public', 'favicon.ico')));
app.use(express.static(path.join(__dirname, 'public')));
app.get('/',function(req,res){
  fs.readFile('./public/login/index.html', function(error, data) {
        if(error != undefined) {
            console.log(error);
            res.writeHead(404);
            res.end();
        } else {
            res.writeHead(200, {'Content-Type': 'text/html'});
            res.end(data);
        }
    });
});

//////////////////////////////////////////////////////////////////////////////////
/////////////////RESTFUL APIS/////////////////////////////////////////////////////
//LOGIN///////////////////////////////////////////////////////////////////////////

app.route('/login')
    .post(function login_post(req,res){
        try{
        //query는 따로 구현하면 됨.
        //var query = require('./query.js');
        query.login([
            req.body.id
            ,salted(req.body.pw)],
            function loginAPI(ret){
            if(ret.fail==0){
                req.session.privilege=ret.result.privilege;
                req.session.uid=ret.result.id;
                req.session.name=ret.result.name;
            }
            res.send(ret);
        });
        } catch(error){
        }
    });

app.get('/logout', function logout_get(req,res){
    req.session.destroy(function logout_destroy(err){
        if(err!==null){
            RESULT.GENERAL_FAIL.result="";
            res.send(RESULT.GENERAL_FAIL);
        } else {
            RESULT.GENERAL_SUCCESS.result="";
            res.send(RESULT.GENERAL_SUCCESS);
        }
    });
});

module.exports = app;

Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg
최근 게시물 이전 게시물 홈

페이지

  • 홈
  • Hobby

Categories

  • AI
  • AWS
  • Blockchain
  • Hardware
  • Javascript
  • Node.js
  • Plasma
  • Security
  • Study
  • Video
  • android
  • mysql
  • review
  • windows

Popular Posts

  • 블랙보드 강의 녹화 영상 다운로드 가능한 방법 (노설치)
    별도의 설치도 필요 없고 아주 쉽습니다. 구글 크롬브라우저 에서 블랙보드 녹화 영상에  다운로드 가능한 메뉴가 나오게 하는 코드입니다.  먼저 블랙보드 강의자료에 입장하고, 재생 버튼을 클릭 하지 않은 상태로 F12 를 입력합니다. 재생을 클릭하지 마...
  • 회사 프록시와 인증서에 고통받는 그대를 위한 글 (Bash, Gradle, Python, wget, nodejs(npm), apt-get, cURL, git, yarn, androidStudio)
    대기업에 입사하면 장단점이 있는데, 단점 중에 하나가 회사에서 프록시를 사용하여 트래픽 감시를 하므로 프록시 설정을 해주어야 한다는 점 입니다. 특히, 회사에서는 https 트래픽도 감시를 하므로 인증서도 설정해 주어야 합니다. 그런데 문...
  • Termux 로 안드로이드에 우분투(GUI)와 VSCode설치하기
      많은 글들이 있지만 뭔가 대부분 잘 안됐다. 이번 기회에 정리한다. 0. 먼저 Termux와 Remote Desktop Manager를 설치한다. Remote Desktop Manager 대신 아래도 나쁘지 않다. 화면이 작지만 마우스 스크롤이나 ...

Blog Archive

  • ▼  2026 (2)
    • ▼  2월 (2)
      • 태블릿에서 양자내성암호(격자암호) 돌려보기
      • 양자컴퓨터와 보안 위협 (쇼어 알고리즘)
  • ►  2025 (3)
    • ►  9월 (1)
    • ►  8월 (1)
    • ►  7월 (1)
  • ►  2024 (2)
    • ►  11월 (2)
  • ►  2023 (2)
    • ►  10월 (1)
    • ►  1월 (1)
  • ►  2022 (10)
    • ►  12월 (1)
    • ►  11월 (3)
    • ►  9월 (1)
    • ►  8월 (1)
    • ►  6월 (2)
    • ►  3월 (2)
  • ►  2021 (9)
    • ►  12월 (3)
    • ►  11월 (1)
    • ►  6월 (1)
    • ►  5월 (2)
    • ►  4월 (2)
  • ►  2020 (12)
    • ►  10월 (1)
    • ►  9월 (2)
    • ►  7월 (1)
    • ►  6월 (1)
    • ►  5월 (5)
    • ►  4월 (1)
    • ►  2월 (1)
  • ►  2019 (14)
    • ►  10월 (2)
    • ►  7월 (1)
    • ►  3월 (4)
    • ►  2월 (2)
    • ►  1월 (5)
  • ►  2018 (14)
    • ►  12월 (2)
    • ►  11월 (4)
    • ►  10월 (1)
    • ►  8월 (2)
    • ►  5월 (4)
    • ►  1월 (1)
  • ►  2017 (12)
    • ►  10월 (2)
    • ►  9월 (9)
    • ►  5월 (1)
  • ►  2016 (8)
    • ►  10월 (2)
    • ►  8월 (1)
    • ►  6월 (1)
    • ►  1월 (4)
  • ►  2015 (6)
    • ►  12월 (3)
    • ►  10월 (1)
    • ►  6월 (1)
    • ►  5월 (1)
  • ►  2014 (10)
    • ►  11월 (1)
    • ►  9월 (1)
    • ►  7월 (1)
    • ►  6월 (1)
    • ►  5월 (3)
    • ►  4월 (1)
    • ►  3월 (2)
  • ►  2013 (28)
    • ►  12월 (3)
    • ►  11월 (6)
    • ►  10월 (6)
    • ►  9월 (6)
    • ►  8월 (1)
    • ►  7월 (3)
    • ►  6월 (3)

구독

글
Atom
글
전체 댓글
Atom
전체 댓글

로드 중입니다...

각오

직접 해보지 않은 것은 포스팅 하지 않겠습니다.

Copyright © 김보안의 블로깅 | Powered by Blogger
Design by Hardeep Asrani | Blogger Theme by NewBloggerThemes.com | Distributed By Gooyaabi Templates