[Review]블록체인 논문 리뷰 - 블록체인 내부자 위협 추적 시스템

블록체인기술을 활용해서 내부자 위협을 막고자 연구된 추적 시스템에 관한 논문을 정리했습니다.
단순 번역에 대한 내용보다는 전체적인 시스템과 실험결과를 바탕으로 중요하다고 생각하는 부분들을 기록하고 추후 제가 다시 확인했을때 참고할 만한 부분을 정리한 내용입니다.

 

* 논문명 : Tracking the Insider Attacker: A Blockchain Traceability System for Insider Threats

* 저널 :  MDPI(Multidisciplinary Digital Publishing Institute) - Sensors

* 논문 사이트 :  링크

논문구성

1. 소개 (스킵)
2. 배경 및 관련연구 (스킵)
3. 위협모델 (스킵)
4. 시스템 구성
5. 실험 및 토론
6. 결과

※ 디테일한 내용은 링크에서 논문받아서 확인

본 논문이 말하고자 하는부분

내부망에서 내부의 위협이 발생했을 때 내부에서 발생한 위협은 추적이 어렵고, 이후에 증거를 얻기 어려운 이유에 대해분석해서 내부자 위협 발생 후 공격자 추적 및 증거 확보 문제를 완화하고 추적 데이터의 무결성을 보장하고 민감한 정보를 보호할 수 있는 블록체인 추적시스템을 고안해냄. 

내부자 공격 유형

본 논문에서는 내부자가 내부망의 환경에 위치하고 합법적으로 접근할 수 있어서 공격자의 흔적이 외부(해킹같은 외부에서의 공격)에서의 공격보다 내부에서 흔적을 지울 가능성이 높기 때문에 내부 위협의 추적 및 포렌식을 극도로 어렵게 한다고함.

1) 개인공격

개인 공격에는 일반사용자(직원) 공격과 관리자 공격이 존재하는데 관리자는 내부 시스템의 활동을 삭제, 변조, 위조, 파괴등 할 수 있음. 
반대로 일반사용자는 보안 탐지 기능에 적발되지 않고 관리자 계정을 얻어 관리자 시스템에 접근할 수 있음(관리자의 과실 or 일반사용자 보안감사 시스템 개발자면 탈취가능).

2) 그룹공격

그룹 공격은 내부의 직원들이 협력해서 중요정보를 탈취

위의 그림의 파란라인은 정상적인 행위, 빨간라인은 내부자 위협 행위이다.

내부의 공격자는 중요자산을 탈취한 후 관리자 계정을 탈취해 시스템 정책(로그 등)을 삭제, 파괴, 변조를
진행한다. 이러한 행위는 내부망에서 인가된 사용자로 인정되기 때문에 보안 시스템(IDS, IPS, SIEM과 같은 탐지, 방지, 모니터링 시스템)에서 악의적인 행위로 간주하지 못할 수 있어서 공격자를 찾는 것이 어렵고 공격의 증거를 추적하고 획득하는 것도 매우 어렵다.

시스템 구성

본 논문의 시스템은 3가지 방식으로 구성되는데

1) 관리자 노드(마스터 노드), 참가자 노드(직원노드)

관리자 노드는 부서의 마스터노드로 참가자 노드가 보낸 노드를 관리, 추적, 블록생성등의 업무를 담당한다.

참가자 노드는 개인(자신)이 생성한 데이터를 트랜잭션으로 패키징해 관리자 노드에게 전송하고 자기 자신만의 정보만 관리한다.

 

2) 프라이버시-체인, 셀프-체인

프라이버시-체인은 모든 노드들이 참여하여 데이터의 추적성과 무결성을 위해 모든 사용자들의 타임스탬프, 시간등의 데이터가 들어간다.

셀프-체인은 개인의 정보를 복사하여 자체 체인에 유지한다. 즉, 참가자 노드의 개인이 개인의 블록체인을 구축해 자신의 정보를 관리한다.

 

3) 차등된 개인정보보호

'Differentially private model publishing for deep learning'링크이 논문의 분석 알고리즘을 [매개변수 ε]를 추출하는데 ε는 보호 정도를 측정하는 파라미터이다.

ε값이 작을경우 보호수준이 높아지고, ε값이 커질경우 보호수준이 낮아진다.

 

데이터 구조

본 논문에서 제시하는 데이터유형

관리자 노드 예시)

해석 : 부서1 마스터노드 / 사용자A 정보 / Device1에 로그인(Activity) t시간 수행

TD  = [[Depart1, MNode], [UserA,  user, ID, hash(UserA)], [Login D1,  t]]

 

참가자 노드 예시)

해석 : 사용자 B 참가자노드 / 파일1.docx / t시간에 Device2에 생성(Activity)

TD  = [[UserB, PNode], [file1, file, docx, hash(file1)], [Create on D2,  t]]

블록 구조 

블록 구조는 생략하고,
트랜잭션 Hash가 ID이고 / Block Height 블록이 위치한 높이 / Serial Number 블록 순서

Signature 거래를 보낸 사용자 전자서명 <- 부인방지용 / Timestamp 트랜잭션 전송된 시간

차등을둔 프라이버시

※ 이부분이 본 논문에서 중요한 부분같은데 알고리즘보고 내가 해석한 내용 맞는건가 싶음..

 

조직 내에서도 다른 부서의 민감정보를 공개하지 않기 때문에, 부서간에서도 민감정보를 보호하기 위한 기술적 조치가 필요한데 이를 본 논문에서는 차등적 프라이버시 기술을 이용해 구분하고자함.

TD데이터를 보내기전에 [매개변수 ε]를 사용해서 차별화된 개인정보를 보호함. 

알고리즘 식인데 

1) TD데이터, 매개변수 ε를 Input으로 넣고

2) TD의 각 속성(DataOwnerName 등) 탐색

3) 속성중 개인정보 보호가 필요한 속성(TD에서 임의로 정하는 방식인듯..?) 일경우

4) N = 개인정보 보호가 필요한 속성의 갯수(Activity면 행동들 총 갯수 N개를 의미하는 건가..?)

5) ti는 올바른 값을 반환할 확률이면 eε / eε + N - 1

6) ti는 다른 속성값을 반환할 확률이면 분자 1 / eε + N - 1

논문에 "where eε represents the probability of returning the correct value of the current attribute, and 1 indicates the probability of returning other attribute values." 이렇게 나와있는데 correct value, other attribute values 이 의미가 몇번을 읽어도 이게 뭘 의미하는지 모르겠음....

 

이렇게 알고리즘을 돌려서 랜덤 응답값을 얻고 개인정보 보호가 필요한 속성이라고 지정한 부분 실제값과 변경.  DIffp(TD)를 얻어냄

Diffp(TD) = [[DataOwnerName, DataOwnerTpye], [DataName, Diffp (DataType), Diffp (DataFormat),
                 Diffp  (DataHash)], [Diffp  (Activity), Timestamp], hash(TD)]

두 블록체인 네트워크 동기화

본 논문에서는 프라이버시-체인과 셀프-체인 두 가지의 블록체인을 동기화 하기위해서 본 논문에서 제시한 동기화 알고리즘을 통해 두 체인을 연결하는 알고리즘을 설계한다.

T시간마다 관리노드가 트랜젹선을 패키징해서 새 블록을 생성하고, 이 새블록이 프라이버시-체인에 추가되는 방식이다.

이때 새블록의 Diffp(TD)를 자신이 소유한 Hash(TD)와 비교한다. Hash(TD) = 트랜잭션.Diffp(TD)

Diffp(TD)는 프라이버시-체인에만 저장되고 일반 참여자는 해당 정보를 얻을 수 없다.

검증 이후 새 블록을 복사하고 복사본에서 해당 트랜잭션의 Diffp(TD)를 TD로 대체하여 새 복제 블록을 구성하고 노드 자체에 추가

실험결과 및 토론

실험 결과 20번의 실험을 반복했을 때 각 Task마다 걸리는 소요시간을 비교한 결과이다.

1) TD생성하고 관리자 노드에게 보내는 시간 - 451 ms and 523 ms

2) Mnode의 트랜잭션을 패키징하고 새로운 블록 생성까지의 소요시간 - 403 ms between and 498ms

3) 새로운 블록생성부터 새로운 프라이버시-체인, 셀프-체인의 최종 동기화까지의 소요시간 -  36.578s and 38.794s (이부분이 가장 오래걸림)

4) 쿼리 추적을 조회하기 위한 응답시간 - 2.698 s and 9.814 s

아래는 노드가 늘어날 수록 반환되는 응답 시간그래프

문제점

1) 본 연구는 소규모 근거리 통신에서 실험을 진행했으며, 실제 네트워크의 호나경에서는 네트워크 지연으로 성능이 저하될 수 있음

 

2) 참여 노드가 추적성 데이터를 패키징하는 시간 간격과 관리 노드가 블록을 생성하는 시간 간격에 대한 연구가 진행될 필요가 있다고 논문에서 언급하고 있음 

 

3) 부서의 규모가 적을경우 비잔티움 문제가 유도될 수 있는듯 본 논문에서도 "부서가 레코드를 집단적으로 조작하여 가짜 데이터를 보내는 악의적인 노드인 경우와 같이 노드가 너무 적다" 라는식으로 문제점을 언급함