블록체인 기반 비상상황 역할 기반 접근제어 시스템

2.1 역할 기반 접근제어

RBAC 모델에는 사용자, 역할 및 권한의 세 가지 기본 요소가 포함되어 있다. RBAC모델은 사용자가 아닌 역할에 권한을 부여한다. 따라서 사용자는 역할 할당을 통해 작업 권한을 얻는다[1]. 시스템은 시스템의 작업에 따라 적절한 역할을 생성한다. 역할이 생성된 후 시스템은 권한을 부여한다. 마지막으로 사용자는 시스템의 보안 요구 사항에 따라 역할에 할당된다. 사용자와 권한은 역할에 따라 연결된다. 따라서 역할을 통해 사용자는 객체에 접근할 수 있다[1].

2.2 비상 역할 기반 접근제어

실제 세계에서 사용자는 때때로 정상적인 상황에서 승인되지 않은 자원에 접근해야 하는 상황이 발생하게 되고, 이 문제를 해결하기 위하여 RBAC에서는 사용자가 제어된 방식으로 접근제어 정책을 재 정의할 수 있도록 하는 BTG 메커니즘이 제안되었다[8]. 따라서 사용자는 일반적으로 정상적으로는 접근할 수 없는 권한에 비상상황에서 접근할 수 있게 된다. 하지만 사용자가 무단으로 다른 역할에 접근을 방지하는 것과 사용자에게 책임을 부여하기 위하여 BTG 상황 시 새로운 권한을 할당받아 일을 해결하는 동안 사용자가 한 행위에 대한 모든 일을 기록하여, 비상상황 시의 작업에 대한 책임을 생성해야 한다[2][4]-[6][9].

다양한 비상상황을 해결하기 위해 사용자의 권한을 기반으로 하는 비상 역할 기반 접근제어 ERBAC 모델이 제안되었다[6].

그림 1은 권한기반 ERBAC 모델을 나타내고 있다[6]. 이 연구에서는 RBAC 정책에 사용자의 권한을 침해하지 않고 최소 권한 원칙을 고수하기 위하여 정상 상황과 비상상황 시에 의무분리와 바인딩 제약조건을 준수하며, 비상상황 시 행하여야 하는 의무 수행 여부에 따라서 시스템의 상태를 제어 모드, 비 제어 모드 두 가지의 경우로 나누어 비 제어 모드로 비상상황이 종료된 후에도 관리자가 직접 감사 기록을 수행하도록 하여 비상상황 처리가 가능하게 하고 있다[6]. 따라서 비상상황 시에 사용자가 새로운 권한을 할당받아 일을 해결하는 동안 사용자가 한 행위에 대한 모든 일을 기록하고, 해당 기록이 훼손되지 않도록 유지하는 것은 사용자가 무단으로 다른 역할에 접근을 방지하기 위하여 매우 중요한 작업이 된다. 불변성, 감사 가능성 및 신뢰성과 같은 특성을 가지고 있는 블록체인은 비상상황 접근제어 시스템의 기반 도구로 매우 적합하게 고려될 수 있다.

Fig. 1.

Permission-based ERBAC model

2.3 블록체인

블록체인은 저장 및 컴퓨팅을 위한 신뢰할 수 있는 플랫폼을 제공하여 접근제어 메커니즘에 더 많은 보안과 투명성을 제공한다. 이 영역에서 많은 접근 방식이 연구되었으며 블록체인을 사용한 접근제어에 대한 이전 연구 중에 비트코인 블록체인을 사용한 연구가 수행되었다. [10][11]은 해당 연구는 사용자 정의 스크립트를 사용하여 접근제어 정책을 실현하고 스크립트를 트랜잭션에 포함시키는 것이다. 비트코인 프레임워크는 범용 프로그래밍 언어를 지원하지 않기 때문에 맞춤형 스크립트는 유연하고 강력한 로직을 수행할 수 없다는 단점이 있다.

위의 연구와 달리 블록체인에서 실행되는 스마트 계약을 활용하는 연구도 활발히 진행되고 있다[12]-[15]. 논문 [12]는 사물 인터넷의 접근제어를 연구하는 것으로 다양한 접근제어 스마트 계약을 포함한다. [13]는 RABC 메커니즘을 이더리움 플랫폼에서 구현한 것으로 조직 간 RBAC 문제에 대처하기 위하여 연구되었다. [14]는 DApp를 위해 SC-RBAC라는 스마트 계약 기반 RBAC 모델을 제시하였으며, 해당 모델에서도 안전하고 감사 가능하며 투명한 접근제어를 제공하기 위하여 스마트 계약을 사용하고 있다. 그러나 해당 모델들은 동적 특성이 미흡하고 세밀한 권한 레벨에서의 제어기 부족한 단점을 가지고 있다. [15]는 위치 인식 RBAC 모델을 스마트 계약을 사용함으로써 블록체인 상에 구현하여 문맥 인식 및 동적으로 역할을 관리하는 연구를 수행하였다. 그러나 이 연구에서도 사용자 인증 방식이 제외되어 있으며, 비상상황 처리를 고려하지 못한 단점이 존재한다.

2.4 신원 기반 서명(IBS, Identity-Based Signature)

본 논문에서는 IBS를 사용하여 엔티티 식별을 제공한다. IBS를 사용하면 엔티티가 이메일 주소, 도메인 이름 또는 물리적 IP 주소와 같은 알려진 ID(ID)에서 공개키를 생성할 수 있다. 개인키 생성기(PKG)라고 하는 신뢰할 수 있는 제 3자가 ID에 해당하는 개인키를 생성한다. PKG는 자신에게 속한 사용자들의 ID에 맞는 개인키를 관리하는 주체이기 때문에, 자신에게 속한 사용자들이 주고받는 모든 데이터를 복호화할 수 있고 서명을 위조 및 변조할 수 있다. 따라서 PKG는 자신이 관리하는 ID를 발급 받은 모든 사용자(사람, 호스트)가 신뢰 할 수 있어야 하며, 어떠한 공격에라도 안전해야 한다.

Kiltz 등[16]은 완전한 IBS 체계를 형성하는 4 개의 알고리즘 세트를 정의했다.

설정 : 이 알고리즘은 마스터 키 쌍 (mpk, msk)을 포함하는 전체 IBS 환경을 만들기 위해 PKG(개인키 생성기)에서 한 번 실행된다.

공개 파라미터 : 마스터 공개키 (mpk: master public-key), 마스터 비밀 키 msk (master secret-key)

KeyDer (서명키 생성) : msk 및 엔티티의 ID를 입력으로, 서명키를 생성한다. 이 알고리즘은 ID에 대한 비밀 서명 키 Isk(Id based signature key)를 생성하기 위해 PKG에서 실행된다.

Sign (서명) : 서명키 Isk 및 메시지 M을 입력으로, 이 알고리즘은 M의 서명 σ를 반환한다.

Vf (증명) : mpk, ID, M 및 서명 σ을 입력으로, 이 알고리즘은 서명 σ가 ID 및 M에 대해 유효하면 1을 반환하고 그렇지 않으면 0을 반환한다.

3.1 시스템 모델

본 논문에서 제안한 시스템 모델은 그림 2에서 볼 수 있듯이 주로 시스템 관리자, 관리 시스템(MS) 및 블록체인(BC)의 세 부분으로 구성된다.

Fig. 2.

Model of the proposed system

시스템 관리자 : 시스템 관리자는 접근제어 정책을 관리하는 관리자로 사용자 역할 및 비상상황 접근 정책을 스마트 콘트랙트를 사용하여 블록체인에 업로드 한다. 또한, 비상상황 시에 수행된 모든 행위들을 블록체인에 업로드 하여 추후의 비상상황 시에 수행된 사용자의 불법행위에 대하여 추적할 수 있도록 한다.

관리 시스템 : 관리 시스템(Management system)은 접근제어를 관리하는 시스템으로 접근 서비스를 제공 할 책임이 있다, 또한 비상상황 시에 수행된 모든 행위들을 블록체인에 업로드 하여 추후의 비상상황 시에 수행된 사용자의 불법행위에 대하여 추적할 수 있도록 한다. 관리 시스템은 블록체인을 유지한다.

블록체인 : 블록체인은 관리 시스템을 감독하는 데 사용된다. 블록체인은 사용자 역할, 비상상황 접근제어 정책/요청/접근결정을 포함하는 감사 레코드를 기록한다. 악의적인 공격자를 방지하기 위해 합의 알고리즘을 사용하여 블록체인 원장이 일관 되도록 한다.

제안된 시스템 모델에서 개인 키 생성기(PKG, Private key generator)는 ID가 있는 엔티티 (관리 시스템, 사용자 및 관리자)에 대한 비밀 서명 키 Isk를 생성한다.

제안된 시스템 모델의 처리과정은 다음단계 1~ 단계 14와 같으며, 표 1은 제안된 시스템에서 사용되는 약어를 설명한다.

Table 1.

Symbols of the proposed system

1단계 : 시스템 관리자는 사용자 역할, 역할의 권한, 의무 분리 및 바인딩 등과 같은 BTG 접근제어 정책[6]을 블록체인에 업로드 하기 위하여 관리시스템에 BTG 접근제어 정책 업로드를 요청한다.

2단계 : 관리시스템은 시스템 관리자를 확인하고, 스마트 콘트랙트를 사용하여 블록체인에 BTG 접근제어 정책 업로드를 요청한다.

3단계 : 사용자는 관리시스템에게 비상상황 시의 접근 요청(access_request)을 수행한다. 사용자는 의 접근요청시 사용자의 IBS 서명키로 서명하고, 관리 시스템의 공개키로 암호화하여 전송한다.

4단계 : 사용자에게서 접근 요청을 받은 관리 시스템은 자신의 비밀 키(개인키)로 접근 요청을 복원하고, uID로 IBS에 적용하여 접근을 요청한 사용자를 확인한다. 관리 시스템은 사용자를 확인한 이후에, 사용자의 역할을 검증하기 위하여 사용자가 속한 블록체인을 찾아서 스마트 콘트랙트를 사용하여 사용자의 역할을 인증한다.

5단계 : 4단계에서 인증된 사용자의 역할 및 접근제어 요청사항을 가지고 블록체인에 있는 BTG 접근제어 정책을 검토하여 스마트 콘트랙트를 사용하여 사용자 접근제어 요청사항의 인가 및 실패를 결정한다.

6단계 : 5단계에서의 결과가 실패인 경우에 비상상황이기 때문에 관리 시스템은 시스템 관리자에게 BTG 접근제어 정책의 변경을 요청하게 된다. 이 요청에 의하여 시스템 관리자는 사용자가 비상상황을 해결할 수 있는 권한을 결정하여 BTG 접근제어 정책을 수정하여 관리 시스템에게 BTG 접근제어 정책 갱신을 요청한다.

7단계 : 관리시스템은 시스템 관리자를 확인하고, 스마트 콘트랙트를 사용하여 블록체인에 BTG 접근제어 정책의 갱신을 요청한다.

8단계 : 변경된 BTG 접근제어 정책으로 비상상황 시 사용자가 속한 역할이 사용자가 원하는 접근 요청을 수행할 수 있는 권한을 가지게 됨으로써, 관리 시스템은 스마트 콘트랙트를 사용하여 사용자의 접근요청에 대하여 블록체인상의 BTG 검사 기록(Audit)에 기록한다.

9단계 : 관리 시스템은 사용자에게 비상상황 시 해당 사용자가 요청한 접근제어 요청의 결과를 반환한다. 관리 시스템은 사용자에게 전달할 데이터를 암호화하는 세션 키를 생성하여 세션 키로 데이터를 암호화한다. 그리고 관리 시스템은 사용자의 공개키로 세션 키를 암호화한 다음, 전달할 데이터의 무결성을 검증하기 위하여 데이터를 해시하고, 해시한 데이터에 관리 시스템의 개인키로 서명을 하여 사용자에게 반환한다.

10단계 : 사용자는 관리시스템으로부터 받은 비상상황 시에 필요한 데이터를 사용하여 비상상황을 해결하고, 비상상황이 종료되면 사용자는 관리시스템에게 비상상황 종료(BTG_end)를 전달한다. 사용자의 비상상황 종료 요청은 사용자의 IBS 서명키로 서명하고, 관리 시스템의 공개키로 암호화하여 전송한다.

11단계 : 사용자에게서 비상상황 종료 요청을 받은 관리 시스템은 자신의 비밀 키로 비상상황 종료 요청을 복원하고, uID로 IBS에 적용하여 비상상황 종료를 요청한 사용자를 확인한다. 관리 시스템은 사용자를 확인한 이후에, 정상 상황으로 복귀하기 위하여 시스템 관리자에게 사용자가 비상상황 시에 받은 권한을 취소하도록 요청한다. 시스템 관리자는 사용자가 비상상황 시에 받은 권한을 취소하도록 BTG 접근제어 정책을 수정하여 관리 시스템에게 수정된 BTG 접근제어 정책 갱신을 요청한다.

12단계 : 관리시스템은 시스템 관리자를 확인하고, 비상상황 시에 받은 권한을 취소하도록 스마트 콘트랙트를 사용하여 블록체인에 BTG 접근제어 정책의 갱신을 요청한다.

13단계 : 시스템 관리자는 관리 시스템으로 부터 받은 비상상황 종료 처리를 수행한 이후에 비상상황 상태가 비 제어 모드(Uncontrolled)인 경우에 수동으로 비상상황 시의 활동들을 감사 기록에 남기기 위하여 비상상황 시의 수행된 모든 관련 활동들의 기록을 관리 시스템에게 요청한다.

14단계 : 관리시스템은 시스템 관리자를 확인하고, 13단계에서 요청받은 기록들을 스마트 콘트랙트를 사용하여 블록체인상의 BTG 검사 기록(Audit)에 기록한다.

3.2 관리자의 비상상황 접근제어 정책 변경

시스템 관리자는 처음에 사용자 역할과 역할의 권한, 의무분리, 바인딩 등 비상상황 접근제어 정책(BTG_policy)을 관리시스템을 통하여 블록체인에 업로드 한다. 시스템 관리자는 자신의 ID와 BTG_policy 그리고 해당 내용을 자신의 ID를 사용한 서명키를 사용하여 서명하고, 식 (1)과 같이 관리시스템 공개키로 암호화하여 관리시스템에 전송한다.

관리시스템은 시스템 관리자로부터 받은 데이터를 식 (2)와 같이 자신의 개인키로 복호화하여 aID || BTG_policy || SignI_ska(aID || BTG_policy)를 복호한다.

그리고 관리 시스템은 aID로 IBS에 적용하여 접근을 요청한 시스템 관리자를 확인한 다음, 비상상황 접근제어 정책을 스마트 콘트랙트(uploadBTGpolicy 함수)를 사용하여 블록 네트워크에 기록한다.

사용자의 접근 권한에 대한 변경은 시스템 관리자에 의해서만 진행될 수 있다. 비상상황 접근제어 정책 변경이 요구되는 경우, 시스템 관리자는 관리 시스템에 비상상황 접근제어 정책 변경(admin_request)을 요청한다. 시스템 관리자는 자신의 ID와 관리요청(admin_request) 그리고 해당 정보를 자신의 서명키(Iska)를 사용하여 서명한 다음, 식 (3)과 같이 관리시스템 공개키로 암호화하여 관리시스템에 전송한다.

관리시스템은 시스템 관리자로 부터 받은 식 (3)을 식 (4)와 같이 자신의 개인키로 복호화하여 aID || admin_request || SignI_ska(aID || admin_request)를 복호한다. 그리고 관리시스템은 aID로 IBS에 적용하여 접근을 요청한 시스템 관리자가 실제 서명한 시스템 관리자가 맞는지 서명을 확인한다.

관리 시스템은 시스템 관리자를 인증하고, 비상상황 시 사용자가 원하는 행위를 수행할 수 있도록 변경된 비상상황 접근제어 정책을 uploadBTGpolicy 함수를 사용하여 블록 네트워크에 기록하고 블록 네트워크는 수행 결과를 관리 시스템에 전달한다. 관리 시스템은 결과를 시스템 관리자에게 전달한다.

그림 3은 시스템 관리자에 의해 비상상황 접근제어 정책을 변경하는 과정을 보이는 순서도이다.

Fig. 3.

Update process of BTG policy of administrator

3.3 사용자의 비상상황 데이터 접근 요청

사용자는 정상 상황에서는 요청할 수 없는 환자의 데이터에 대하여 비상상황 시에 해당 데이터에 접근을 요청할 수 있다. 예를 들어 비상상황이 발생하여 의사가 자신이 권한 밖의 환자 데이터를 읽으려고 한다면, 의사는 관리시스템에 비상상황으로 데이터 접근 요청을 한다.

사용자의 데이터 접근 요청은 사용자 ID(uID), 환자 ID(patientID), 접근 요청(access_request)과 해당 내용에 대한 서명으로 이루어진다. 사용자는 자신의 Isk_u(ID 기반 서명키)를 사용하여 서명하며, 해당 요청사항을 식 (5)와 같이 관리시스템의 공개키로 암호화 하여 관리시스템으로 보내게 된다.

관리시스템은 사용자의 요청사항을 받아서 식 (6)과 같이 자신의 개인키로 복호화하여 uID || patientID || access_request || 서명을 복원하게 된다.

관리시스템은 uID로 IBS에 적용하여 접근을 요청한 사용자가 실제 서명한 사용자가 맞는지 확인하고, 사용자의 요청에 대한 접근 여부를 결정한다. 관리 시스템은 사용자의 역할을 검증하기 위하여 사용자의 블록체인을 찾아서 스마트 콘트랙트(getURole)를 사용하여 사용자의 역할을 인증하고 가져온다. 그리고 관리시스템은 사용자의 인증된 역할 및 요청사항을 가지고, 블록체인에서 자신(관리 시스템)의 공개키를 키로 사용하여 getPolicy를 호출하여 비상상황 접근 정책을 검색한 이후에 비상상황 접근 정책을 가져온다. 블록체인에 있는 BTG 접근제어 정책을 검토하여 스마트 콘트랙트를 사용하여 인가 및 실패를 결정한다.

관리시스템은 비상상황 접근정책 검토 결과가 실패가 나오는 경우에 비상상황 시의 사용을 위하여 시스템 관리자에게 비상상황 접근 권한 갱신을 요청한다. 관리 시스템은 데이터를 암호화하는 세션 키(key)를 생성하여 세션 키로 데이터를 암호화하고, 시스템 관리자의 공개키로 세션 키를 암호화한다.

그리고 관리 시스템은 식 (7)과 같이 비상상황 접근 권한 갱신 요청을 해시하고, 해시한 데이터에 관리 시스템의 개인키 sk_MS로 서명하여 시스템 관리자에게 요청한다.

시스템 관리자는 식 (8)과 같이 자신의 개인키로 세션 키를 복호하여 세션 키를 구한 다음, 해당 세션 키로 비상상황 접근 권한 갱신 요청을 복호한다. 그 이후에 시스템 관리자는 비상상황 접근 권한 갱신 요청을 해싱하고 수신 받은 서명된 해시 값을 관리시스템 공개키로 복호화한 값과 비교함으로써 수신 받은 비상상황 접근 권한 갱신 요청의 무결성을 보장받는다.

시스템 관리자는 권한 기반 ERBAC [6]에 따라서 비상상황 해결을 위하여 사용자의 역할에 추가할 권한을 결정하고, 식 (3)와 같이 비상상황 정책 수정을 요청한다. 관리 시스템은 시스템 관리자에게서 받은 요청을 식 (4)와 같이 관리 시스템의 개인키를 사용하여 복호한 다음, 시스템 관리자를 인증하고, 스마트 콘트랙트를 사용하여 수정된 비상상황 접근제어 정책을 블록체인의 해당 블록에서 갱신한다. 그 이후에 해당 사용자는 비상상황 시에 본인이 요청한 권한을 사용할 수 있게 된다. 따라서 관리시스템은 비상상황 시의 사용자 행위에 대한 추후 감사를 수행할 수 있도록, 스마트 콘트랙트(Recordaudit 함수)를 사용하여 사용자의 요청 내용을 자신(관리 시스템)의 블록체인 상의 BTG 검사 기록(Audit) 블록에 기록한다.

그리고 관리 시스템은 사용자에게 해당 사용자가 요청한 데이터를 반환한다. 관리시스템은 데이터를 암호화하는 세션 키를 생성하여 세션 키로 데이터를 암호화하고, 사용자의 공개키로 세션 키를 암호화한다. 그리고 관리시스템은 데이터를 해시하고, 해시한 데이터에 관리 시스템의 개인키 sk_MS로 서명하여, 식 (9)와 같이 사용자에게 반환한다.

사용자는 식 (10)과 같이 자신의 개인키로 복호하여 관리시스템 세션 키를 구하고, 해당 세션 키를 사용하여 암호화한 data를 복호하고, 복호한 data를 해시함수에 적용하여, 수신 받은 서명된 해시 값을 관리시스템 공개키로 복호화한 값과 비교함으로써 수신 받은 데이터의 무결성을 보장받는다.

그림 4는 비상상황 시에 사용자의 데이터 요청을 처리하는 과정을 보여준다.

Fig. 4.

Process of user access request in emergency situation

4.1 트랜잭션

블록체인 시스템에서 트랜잭션은 트랜잭션 헤더와 페이로드의 두 부분으로 구성된다[17]. 시스템에서 요청 트랜잭션은 사용자 ID(uID), 환자 ID(patientID), 접근 요청 및 서명으로 구성된다. 즉, TXrequest = uID || patientID || access_request || 서명이다.

예를 들어 비상상황이 발생하여 의사 Bob이 환자 Alice의 데이터를 읽으려고 한다고 가정하면, Bob은 다음과 같은 요청을 관리시스템에게 해야 한다. Bob은 ID_Bob || ID_alice || record_read || SignI_skBob(ID_Bob || ID_alice || record_read)을 관리 시스템에 전송한다. 여기서 ID_Bob은 Bob의 ID, ID_alice은 Alice의 ID, record_read 는 "레코드 읽기"의 접근 요청 및 Sign은 디지털 서명 체계를 사용하는 서명을 나타낸다.

4.2 스마트 계약

스마트 계약은 일부 실행 가능한 논리를 정의한다. 스마트 계약은 블록체인에 설치되며 트랜잭션에서 호출되는 인터페이스를 제공하는 기능을 정의한다.

제안된 시스템에서 신뢰할 수 있는 접근제어 프로세스를 제공하기 위해 시스템 관리자는 관리 시스템을 통하여 접근제어 스마트 계약을 사용하여 사용자의 역할, 역할의 권한, 의무 분리 및 바인딩 등 비상상황 접근 정책을 블록체인에 업로드 한다. 또한 관리 시스템은 블록체인에 기록된 역할 및 비상상황 접근 정책을 기반으로 접근 결정을 내리기 위해 스마트 계약인 AccessDecision 함수를 사용한다.

신뢰할 수 있는 감사를 제공하기 위해 우리는 사용자의 요청과 accessDecison의 접근 결정을 포함하여 비상상황 시의 모든 활동에 대한 감사 기록을 기록하는 스마트 계약을 설계한다. 스마트 계약은 주로 다음과 같은 다양한 기능 인터페이스를 제공한다.

uploadURole(uID, uRole, sig) : 이 함수는 그림 5와 같이 관리 시스템에 의해 호출되며 사용자의 역할을 블록체인에 업로드 하는데 사용된다. 관리 시스템은 사용자의 ID(uID), 역할 및 관리 시스템의 개인키로 서명한 서명을 전송하여 이 기능을 호출한다. 이 함수는 관리 시스템이 서명한 서명이 해당 관리 시스템이 서명한 것인지를 인증하기 위하여 서명을 확인한다. 그런 다음 블록체인은 사용자의 역할을 검색하기 위하여 uID에 대한 사용자 공개키(uPK)를 키로 사용하며, 해당 역할을 검색한 이후에 사용자의 역할을 저장하거나 업데이트한다.

Fig. 5.

uploadURole algorithm

uploadBTGPolicy(aID, policy, sig) : 이 함수는 그림 6과 같이 관리 시스템에 의해 호출되며 비상상황 접근 정책을 블록체인에 업로드 하는데 사용된다. 관리 시스템은 비상상황 접근 정책 및 관리 시스템이 서명한 서명을 전송하여 이 기능을 호출한다.

Fig. 6.

uploadBTGPolicy algorithm

이 함수는 관리 시스템이 서명한 서명이 해당 관리 시스템이 서명한 것인지를 인증하기 위하여 서명을 확인한다. 그런 다음 블록체인은 비상상황 접근 정책을 검색하기 위하여 관리자 공개키를 키로 사용하며, 비상상황 접근 정책을 검색한 이후에 관리 시스템 공개키를 이용하여 암호화하여 비상상황 접근 정책을 저장한다.

ChangePermission(aID, Perm_Info, sig): 이 함수는 그림 7과 같이 비상상황 시 시스템 관리자가 동적으로 비상상황 접근 정책을 제어하기 위하여 사용한다. 이 함수는 시스템 관리자의 요청에 의하여 관리 시스템에 의해 호출되며 비상상황 접근 정책 중에 권한 생성을 동적으로 블록체인에 업로드 하는데 사용된다. 관리 시스템은 권한 정보 및 관리 시스템이 서명한 서명을 전송하여 이 기능을 호출한다. 이 함수는 먼저 서명을 한 관리 시스템이 이 함수를 호출한 관리 시스템인지 인증하기 위하여 서명을 확인한다. 그런 다음 블록체인은 비상상황 접근 정책을 검색하기 위하여 시스템 관리자 공개키를 키로 사용하며, 비상상황 접근 정책을 검색한 이후에 관리 시스템 공개키를 이용하여 암호화하여 비상상황 접근 정책을 업데이트한다. 그리고 비상상황 접근 정책을 업데이트한 내용을 블록체인의 감사레코드에 기록한다.

Fig. 7.

ChangePermission algorithm

getURole(uID) : 이 함수는 그림 8과 같이 관리 시스템에 의해 호출되며 사용자의 역할을 블록체인에서 다운로드 하는데 사용된다. 사용자의 ID를 받으면, 이 함수는 블록체인으로 부터 사용자의 역할을 검색하기 위하여 사용자 공개키를 키로 사용하여 해당 역할을 검색한 이후에 사용자의 역할을 반환한다. 사용자의 역할에 대한 검색이 실패하면 role_error를 반환한다.

Fig. 8.

getURole algorithm

getBTGPolicy(a_ID) : 이 함수는 그림 9와 같이 관리 시스템에 의해 호출되며 비상상황 접근 정책을 블록체인에서 다운로드 하는데 사용된다. 시스템 관리자의 공개키가 수신되면, 이 함수는 블록체인에서 시스템 관리자의 공개키를 키로 사용하여 비상상황 접근 정책을 검색한 이후에 비상상황 접근 정책을 반환한다. 비상상황 접근 정책에 대한 검색이 실패하면 BTGpolicy_error를 반환한다.

Fig. 9.

getBTGPolicy algorithm

AccessDecision(request, sig) : 이 함수는 그림 10과 같이 관리 시스템에 의해 호출되며 접근 결정을 내리는 데 사용된다. 접근 요청이 수신되면 접근을 요청한 사용자가 실제 서명한 사용자가 맞는지 사용자 공개키로 서명을 확인한다. 그리고 getURole을 호출하여 사용자의 역할을 가져오고, getBTGPolicy를 호출하여 비상상황 정책을 가져온다. 그런 다음 사용자 역할이 비상상황 접근 정책을 충족하는지 여부를 결정한다. 마지막으로 recordAudit를 호출하여 블록체인에 감사 레코드를 기록하고 허가 여부를 반환한다.

Fig. 10.

AccessDecision algorithm

recordAudit(request, decision) : 이 함수는 그림 11과 같이 사용자의 요청, 요청한 접근 시간 및 accessDecison의 접근 결정 즉 role_error, BTGpolicy_error, access_error, sign_error, permit을 블록체인에 기록하는 데 사용된다.

Fig. 11.

recordAudit algorithm

4.3 시스템 구축

시스템 설정, 접근제어, 데이터 전송 및 분쟁 처리를 포함하여 시스템의 4가지 주요 단계가 있다.

시스템 설정 : 시스템 관리자는 관리 시스템을 통하여 uploadURole, uploadPolicy를 호출하여 사용자의 역할, 비상상황 접근 정책을 블록체인에 업로드 한다.

접근제어 : 사용자가 접근 요청을 시작하려는 경우 자신의 요구 사항에 따라 요청을 구성한다. 예를 들어, 비상상황이 발생하여 사용자가 환자의 데이터를 읽고 싶어 한다고 하자. 이 경우 사용자가 생성 한 요청은 request = (uID, patientID, read, sig)이며 sig는 sigI_sku(uID, patientID, read)로써 사용자가 데이터 무결성을 위하여 서명한 것이다. 사용자는 관리 시스템에게 자신의 요청을 전달하고, 관리 시스템은 AccessDecision을 호출하여 접근 결정을 한다. 비상상황이기 때문에 비상상황 접근정책 검토 결과가 실패가 나오는 경우에 관리시스템은 시스템 관리자에게 비상상황 접근 권한 갱신을 요청한다.

시스템 관리자는 허가 기반 ERBAC 정책[6]에 따라서 비상상황 해결을 위하여 사용자의 역할에 추가할 권한을 결정하고, 비상상황 정책 수정을 요청한다. 관리시스템은 시스템 관리자에게서 받은 요청을 스마트 콘트랙트를 사용하여 블록체인의 해당 블록을 갱신한다. 그 이후에 해당 사용자는 비상상황 시에 본인이 요청한 권한을 사용할 수 있게 된다. 그리고 신뢰할 수 있는 추후 감사를 제공하기 위해 관리시스템은 사용자의 요청과 AccessDecison의 접근 결정을 포함하는 비상상황 시의 모든 활동에 대하여 스마트 콘트랙트를 사용하여 자신의 블록체인 상의 BTG 검사 기록 레코드에 기록한다.

데이터 전송 : 블록체인을 통하여 관리 시스템에 접근 결정이 수신되면 관리 시스템은 데이터 리소스에 접근 할 수 있는 사용자에게 데이터를 반환한다. 관리 시스템은 데이터 전송 시 기밀성을 유지하기 위하여 데이터를 암호화하는 세션 키(Key)를 생성하여 세션 키로 데이터를 암호화하고, 세션 키를 보호하기 위하여 사용자의 공개키로 세션 키를 암호화 한다. 그리고 관리 시스템은 데이터의 무결성을 보장하기 위하여 데이터를 해시하고, 해시한 데이터의 신원 확인을 위하여 관리 시스템의 개인키로 서명을 한 다음, 전체 데이터를 사용자에게 반환한다.

분쟁 처리 : 사용자는 관리시스템으로 온 전체 데이터 중에서 자신의 개인키로 세션 키를 복호하고, 복호한 세션 키를 사용하여 접근 요청 결과 데이터를 복호한다. 그 이후에 사용자는 복호한 데이터를 해시하여 관리시스템의 공개키로 해시 값(H(data))을 복호하여 비교함으로써, 전송된 접근 요청 결과 데이터의 무결성을 확인할 수 있다. 그리고 관리 시스템은 블록체인상의 사용자 감사 레코드 기록을 사용하여 사용자의 접근 기록을 추적할 수 있으므로 비상상황 시의 사용자의 비정상적인 접근 동작을 감지 할 수 있다.