[회고록] 코드스테이츠 프로젝트 DID 인증 서비스의 가치는?

2022.09.01 - [Blockchain] - [회고록] 코드스테이츠 프로젝트 3 시작 (DID 인증 서비스)

[회고록] 코드스테이츠 프로젝트 3 시작 (DID 인증 서비스)

 

코드스테이츠에서는 총 3번의 프로젝트를 진행하게 된다. 그 중 3번째 프로젝트는 기간도 한달로 가장 길고, 많은 기능들을 만들어 볼 수 있는 좋은 기회다. DID 서비스를 구현하는 프로젝트에 참여하게 되었고, 백엔드, API, Database 부분을 맡아서 작업을 시작했다.

 

프로젝트 문제의 시작

 

프로젝트를 시작할 때 우선 서비스의 개념을 구체적으로 정의를 해야 한다. 어떤 문제를 해결할 수 있을지, 효율적으로 문제를 해결하는 방법은 어떤 것들이 있는지, 고민해보고 이를 시각적으로 문서화 하는 작업이 우선 되어야 한다. 시작은 순조로웠다. 

 

 

 

 

우선 DID가 뭔지 개념을 팀원들끼리 머리를 맞대고 고민했고, 어떻게 구현해낼지 생각했다. 프론트, 백엔드, 스마트 컨트랙트 부문으로 꼭지점을 정하고, 역할 분담을 진행한다. 어떤 분야든 전체적인 그림이 그려져야 하기 때문에, 이를 위한 문서화 작업도 진행한다.

• 프론트 : WireFrame(Figma)
• 백엔드 : DB 스키마(db diagram), Insomnia API testing
• 프로젝트 : Flowchart
• 협업 Tool : Github

전체 프로젝트 컨셉잡고, 문서화 작업을 하는데 1주일 정도 시간이 소요되었다. DID를 찾아볼 수록 W3C에서 표준을 제공한다고 하지만 사실 우리가 정한 블록체인은 Klaytn이고, 이에 대한 표준이 명확하게 지정되지 않은 상태였다. VC, VP를 어떻게 발급할지, 어떤 정보를 담을지에 대한 정의가 우선되어야 했다.

프로젝트가 중간쯤 지나고 wireframe이나 DB Diagram을 작성하는데 1주일 정도 시간 소요되었고, 코딩을 시작해서 실제 기능 구현까지 뽑아내는데는 1주일 정도 걸렸다. 코드스테이츠에서 프로젝트를 진행하면 멘토가 한분씩 참여하셔서 프로젝트 전반의 컨셉과 문제점들을 뽑아주신다. 여기서 문제가 발생한다.

 

프로젝트 핵심 가치 ??

 

진행하고자 하는 프로젝트가 어떤 문제를 해결할지, 어떤 부분에 초점을 맞추고 있는지에 따라 같은 주제라 하더라도 결과물은 천차만별로 바뀌기 마련이다. 최초 팀원들과 고민했을 때 DID 프로젝트의 가장 큰 가치는 "보안"이라 생각했다. 따라서 Issuer/Holder/Verifier 간 민감한 개인정보가 담긴 VC,VP가 이동할 때 암호화에 신경을 많이 썼다. 

멘토님의 의견은 DID의 가치는 보안보다는 "증명"에 있다는 말씀을 해주신다. 즉, 굳이 속도도 느리고 보안에도 취약한 퍼블릭 블록체인을 사용해서 DID를 구현하는 이유는 속도, 보안을 포기하고 위변조를 불가능하게 만드는 블록체인의 특성 때문이라는 것이다.

이 개념 하나로 인해 프로젝트 전반의 코드가 변경되는 건 아니지만, 중간 정도에 좋은 의견을 주셔서 VC를 저장한 후 인증 요청을 하는 과정을 블록체인의 특성을 최대한 살리는 방향으로 정하게 되었다. 기존 컨셉에서는 비대칭키를 이용한 암/복호화 작업이 많이 들어갔다.

1. Holder가 Issuer에게 VC를 요청한다.(VC를 작성한 후 Issuer의 PrivateKey로 암호화 진행)

2. Issuer가 발급한 VC는 IPFS에 업로드한다.(Holder의 PublicKey로 암호화 진행)

3. VC를 소유한 Holder는 VP를 생성한 후 Verifier에게 인증요청을 한다.(Holder의 PrivateKey로 복호화 + Verifier의 PublicKey로 암호화)

4. Verifier는 요청된 VP를 통해 인증을 진행하고 결과물을 가져온다(Verifier의 PrivateKey로 복호화 + Issuer의 PublicKey로 복호화 + Holder의 PublicKey로 복호화)

Holder가 VC를 요청하고 인증에 성공하기 까지 7번의 암/복호화가 진행된다. 여기서 문제는 성능이 좋지 않은 비대칭키로 모든 암/복호화 과정이 이루어진다는 점이다. localhost 환경에서 VC를 요청하고 인증에 성공하는데 response rate가 6초가 넘게 걸리는 대참사가 발생했다.

디지털 서명 방식 암호화(비밀키 암호화 + 공개키 복호화)는 JWT 로 사용할 수 있었는데, 공개키 방식은 JWT에서 지원하지 않아, Node.js의 crypto 모듈을 사용해 공개키 방식 비대칭키 암/복호화 과정을 구현했다. 여기서 추가적인 문제가 또 발생한다. 

추가 문제점은 RS256 알고리즘을 사용해 암복호화 하는 과정에서 Issuer가 생성한 VC의 길이가 너무 길어져서 공개키 보다 긴 문자열은 암호화가 안되는 사태가 발생한다. 이 문제를 해결하기 위해 VC를 350Byte로 쪼개서 암호화 복호화를 진행했다. Issuer 비밀키로 암호화된 VC의 문자열 길이는 약 1300~1400Byte 정도였으니, Holder의 암/복호화 하고 Verifier의 암/복호화 과정이 각 4번씩 총 8번이 들어갔다. 결과적으로 19번의 암/복호화를 해야되는 상황이 발생하게 된 것이다.

 

 

 

 

결과적으로 보면 단 한번의 DID 발급/요청/인증을 완료하는데 19번의 암복호화 과정이 필요하게 되었고, 실제 DB에 저장되는 데이터의 양 또한 굉장히 늘어났다. DB는 MongoDB를 사용하는데, 사실 NoSQL의 장점을 하나도 살리지 못하는 결과물이 나오게 된 것이다. 

놀랍게도 데이터 전체의 1/3이 이정도다

 

아직 시간은 많다

 

사실 전체 프로젝트에서 1/2 정도 지난 시점에서 MVP는 뽑아냈고, 테스팅도 Insomnia 환경에서나마 테스트를 다 완성한게 그나마 다행이었다. 멘토님께 결과물을 보여드리고 실질적인 피드백을 받을 수 있어서 좀더 건설적인 방향으로 새로운 방향을 잡을 수 있었다.

일단 IPFS에 VC를 업로드하는 방식은 기형적인 방식이기도 하고, 블록체인을 최대한 활용해서 '증명'의 가치를 뽑아내기로 한다. VC는 블록체인에 저장하고 Verifier는 블록체인에 저장된 DID Document 내의 VC로 위변조가 되지 않았다는 확신을 얻을 수 있게 된다. 

 

 

1. 블록체인 활용 Flow Chart

① 발급받은 VC는 블록체인에 비대칭키로 암호화해 해시 형태로 저장한다.

② Verifier는 4가지 정도 factor로 VP의 인증 결과를 판단한다.

③ 가스비는 전적으로 컨트랙트 발행자(Admin) 계정으로 부담한다.

2. 추가 아이디어

블록체인을 퍼블릭이 아닌 프라이빗 혹은 컨소시엄 블록체인으로 구성하면 블록체인에 올라가는 정보를 어느정도 보호할 수 있을 것으로 보인다. 따라서 Issuer나 Verifier가 회원가입할 때 Admin에게 요청을 보내는 식으로 돌리고, Admin 계정에서 Issuer / verifier의 회원가입을 승인해주는 형식으로 바꾼다.

이 로직은 불특정 다수가 Issuer나 Verifier로 참여하는 것을 방지할 수 있고, 신뢰할 수 있는 기관을 서비스에 참여시킬 수 있는 신뢰의 기반이 될 수 있을 것으로 보인다. 

 

더 해볼 것들

 

서비스에서 중요한 건 서버가 얼마나 많은 요청을 효율적으로 처리해내느냐 일 것이다. 서버의 응답은 요청마다 다르지만 평균값에 오차범위가 크지 않도록 관리할 필요가 있다. 서버에게 큰 부담을 주는 녀석 중 하나가 바로 DB에서 데이터를 읽어오고 쓰는 과정이다. 

서버 성능을 테스트 하기 위해서 TDD로 Jest를 사용해보거나, Artillery로 StressTest를 진행해보는 것도 좋은 경험이 될 듯하다. 또한  DB성능을 향상시키기 위한 DB 이중화나 실제 AWS / Heroku 등 호스팅 서비스에 실제 배포를 해서 서비스를 운영해보는 것도 좋겠다.

 

 

Advanced

1. Jest Test Code 작성
2. Artillery Stress Test 진행 
3. Deploy(AWS / Heroku) with Docker
4. DB Replica Set Config
5. Contract Proxy Config
6. Klaytn 수수료 위임

 

 

 

JWT 비대칭키로 암호화 복호화 하는 법

 

Truffle develop account 확인 (기본 사용 방법)

 

Mocha Chai framework for testing install