remove key 메모리상에서도 필요할것 같습니다!

[de-labtory]

remove key 메모리상에서도 필요할것 같습니다!

[owljoa]

너무 오랜만이라 죄송합니다.. 요근래 정신없는 일이 있어서..

하이퍼레저 문서에서 일부 내용을 보니 키 관리를 위해 특정 하드웨어를 사용하는것으로 보이네요.. ㅠ
그리고 키 관리는 fabric에서는 다루지 않는다고 하고.. 위 내용은 composer github 저장소에서 본 내용입니다.

저희는 하드웨어 개발은 할수는 없으니 일단.. 키 관리에 대한 복잡한 문제는 뒤로하는것이 좋을듯 합니다.

1. 키를 암호화해서 저장하는 로직 추가 : 암호화 키는 파라미터로 받겠지만 예시 코드로는 기본적으로 사용자 입력 패스워드로 하는 것이 좋을것 같습니다.(편한 개발..)

2. 서명키 메모리 해제 로직 추가 : 서명키가 평문상태로 메모리에 있는 시간은 서명기능에서 지연시간의 제한 x초를 파라미터로 입력받아서 최소화하는것으로 제안을 드렸고 두분 모두 오케이 하신 것 같습니다 :)

3. 찾아보니 SKI(Subject Key Identifier)는 인증서의 계층 구조(체인)에서 경로를 위한 식별자라네요.
   그리고 하나 더 필요한것이 AKI(Authority Key Identifier)이고..
   예를 들면, rootCA는 인증서에 자신의 public key, SKI를 포함하고(다른 요소들은 생략), 이 rootCA가 인증서를 발급한 특정 기관 CA1의 인증서에는 CA1의 public key, SKI, AKI(rootCA의 SKI)를 포함하고, 이 CA1에서 발급한 특정 노드 N1의 인증서에는 N1의 public key, SKI, AKI(CA1의 SKI)를 포함하는 형식입니다.

-> 이렇게 만들어진 계층의 AKI를 이용하면 인증서 발급기관을 쉽게 찾을 수 있다는 그런.. 의미인것으로 보입니다.
-> 그래서 private key에 대해서는 SKI를 생성하지 않아도 될것으로 보입니다.

그리고 위 1번, 2번 두가지는 오늘부터 또 조금씩 구현 시작해보겠습니다!

[owljoa]

@junbeomlee

1. 넵!

2. private key는 개인 혹은 기기를 증명(인증)할 수 있는 중요한 리소스이기 때문에 메모리상에 평문형태로 오래 유지하는건 안전하지 않다고 생각했습니다! 암호화하지 않은 인코딩만된 형태의 키 파일도 안전하지 않은것으로 보입니다.
   그래서 또 한가지 질문드리고 싶은건 키를 저장할 때도 암호화 과정 없이 인코딩만 하는것으로 보이는데 암호화는 서비스단에서 해야하는 일 일까요?

3번의 말씀대로 진행한다면
지금 keyManager가 가지고 있는 generator, loader, storer, pubkey, prikey들을 각각의 주체(?)로 분리해서 각각의 역할로써 사용할 수 있게하고, (키가 무언가를 행하는게 아니기 떄문에 키는 주체(?)는 아니겠네요)

"키를 받아서 어떤 로직을 수행" 이 부분은 서명/검증을 말씀하시는것 같은데 이부분은 Auth에서 해주고 있어서 keyManager를 제거하면 될 것 같습니다.

말씀하신 부분을 제가 잘 받아들인게 맞나요?

[owljoa]

그러면,,

1. 키 파일 저장시 암호화 과정 추가

2번은 메모리에 키를 계속 유지하지 않고 서명할때마다 파일로부터 키를 로드하는것을 말씀하시는거죠??
그렇다면,, 3번은 무슨 말씀이신지..

1. 2번에서 1sign 1 key load 방식으로해서 메모리에 키를 올려두는 시간을 최소화 하면 3번은 불필요하지 않을까요?

2. 아니면 sign하는 시점 이외에는 암호화를 해서 메모리에 계속 private key를 유지하자는 말씀이신가요?
   이렇게되면 서명키를 암호화할때 사용하는 비밀키를 서명할때마다 load해야합니다. 1)의 방법보다 비효율적으로 보입니다.

그리고 제가 처음 제안드린 부분은 메모리에 키가 올라가 있는 시간을 최소화해야 한다는 것 이였습니다.
그러기 위해서는 위에 말씀드린 1)의 방법이 가장 안전한 방법인 것으로 생각합니다.

그런데 제가 혼란을 드린것은 개인과 기기에 대한 예를 들었던 것이네요 ㅠ..
다시 생각해보니 파일형태로 서명키를 암호화하는 기능(라이브러리에서 제공)은 저희가..
서명키를 암호화한 비밀키는 안전하게 보관(라이브러리를 이용하는 서비스 개발자가 제공)하도록 하는것은 서비스 개발자들이나 서비스 이용자들이 할 일인것 같습니다.

라이브러리는 모든 서비스에 맞출수는 없고 프라이빗 블록체인도 물류, 금융, 기업간 거래, 원산지 추적 등등 많은 서비스에 적용될수 있기 때문이죠.

==================================================================

결론적으로는 서명키를 암호화하는 로직은 구현하되, 어떤 형태의 암호화키(서명키를 암호화하는)를 사용하는지는 디폴트는 패스워드로 두고 다른 형태도 받을 수 있도록 열어두는게 좋을것 같습니다.
그리고 메모리상에 올려두는 시간도 서비스 개발자들이 정의할 노드와 트랜잭션을 날리는 빈도를 체크해서 1회 서명 후 서명키를 메모리상에 올려둘 시간을 선택할 수 있도록 하는것이 좋지 않을까 합니다.

[junbeomlee]

아아 제가 말을 잘못한게 있었는데 파일뿐만 아니라 메모리 자체도 평문으로 저장하지 말고 암호화 하자는 의미였습니다. 메모리를 지우는 일은 비효율적인게 노드가 외부로 데이터를 전송할때마다 서명을 해야되서 짧은 시간내에 많은 서명을 수행 할 것 같아서 (제 생각에는 1초에 몇 십번의 서명도 수행해야할 듯 합니다) 메모리를 지우는 것보다 차라리 메모리 자체도 암호화 하는 것으로 제안 드렸습니다!!

[owljoa]

아! 그러면..

메모리상에 서명키를 암호화된 상태로 유지하고 서명을 수행할때마다 복호화해서 사용하자! 는 말씀이시군요!

그런데 이렇게 구현을 해두면 제가 앞에 말씀드린거서럼 서명키를 암호화할때 사용하는 암호화키를 계속 불러와야합니다. 저 암호화키도 메모리내에 평문으로 두면 위험하고요.

그래서 @junbeomlee 님의 말씀처럼 1초에 수십번의 서명을 수행해야할 경우에 1서명 1키 로드가 비효율적이라면, 서명 후 다른 서명이 수행되지 않는 지연시간(?)이 x초를 넘어가면 서명키에 할당된 메모리를 해제하는것이 어떨까요? (x초는 물론 라이브러리를 이용하는 분들이 파라미터로 넣는 값 일것입니다!)

@yojkim 님의 생각은 어떠신지요 !?

[junbeomlee]

@owljoa @yojkim
좋은 제안을 해주셨는데

1. remove key를 메모리에서 지우는 로직이 추가되어야할 것 같습니다. 현재는 file만 지우고 있네요!
2. private key를 메모리에 올린다고 해서 안정성이 떨어진다는 부분은 잘 이해하지 못했습니다. 저는 크게문제가 없다고 생각하고 있는데 어떤 문제점들이 발생할 수 있을지를 말씀해주시면 더좋을 것 같습니다.
3. KeyManagerImpl쪽을 보니 내부적으로 KeyManagerImpl가 Key를 가지고 있는 형태가 라이브러리로의 자율성을 많이 해치고 있다는 생각이 들었습니다. 예를 들어 ByteToKey 함수의 경우 KeyManager를 만들어야만 ByteToKey를콜할 수 있는데 리턴으로 pubkey를 해주는것이 아닌 내부적으로 Key를 저장하는 구조를 가지고 있어서, Key만 사용하고 싶은데 계속 KeyManagerIml를 가지고 있는 형태를 가지고 있어서, 구조체와 로직의 구분이 필요한것 같습니다. 개인적으로는 Key를 내부적으로 존재하는것 보다 생성시 return 해주는것으로 하고 그 키를 받아서 어떤 로직을 수행해주는 부분만 KeyManagerIml에서 구현되어야 사용자 입장에서 유연하게 사용 가능 할 것 같습니다.

3번을 너무 막 설명하다보니 이해가 안되는 부분이 있을 것 같습니다. ㅠㅠ 의견 답글로 달아주세요!!

[junbeomlee]

@owljoa
2번에 관해서 암호화 과정은 이 라이브러리에서 추가되어야할 좋은 제안 인것 같습니다. 서비스단에서 수행하지 않고 이 라이브러리에서 암호화된 키를 저장하는 것이 추가되면 좋을 것 같습니다!!
메모리상에 평문으로 존재하더라도 그것을 탈취해갈 수 있는 위험이 존재한건가요?!! (이부분은 제가 잘 모르겠는데 메모리보다는 파일 탈취위험이 더 크지 않나요?!)

3번에서 모두 분리하는 것은 아니고 key와 나머지(generator, loader, storer)의 분리가 필요하다고 생각하고 있습니다.

type keyManagerImpl struct {
	path       string
	generators map[KeyGenOpts]keyGenerator
	loader keyLoader
	storer keyStorer
}

즉 keymanager에서는 key를 가지고 있지 않은 형태로!!

"키를 받아서 어떤 로직을 수행" 이 부분은 표현을 제가 잘 못해서 그랬는데 "키와 관련된 로직 수행"이 맞을 것 같고 서명/검증 분만 아니라 load, store등등 모든 키와 관련된 기능들을 얘기한 것 입니다.

[owljoa]

@junbeomlee
2번 - 저도 해킹 부분은 아주 잘은 모르지만, 보통 비밀키, 개인키, 서명키 같은 중요한 키들은 코드의 영향을 받지 않는 요소(패스워드, 생체정보 등)로 암호화해서 파일형태로 안전하게 보관하는 것이 좋다고 하고요. 메모리상에서 위험한 이유는 키를 어떤 로직에서 필요로 할 때 복호화된 평문형태로 올리기 때문이에요. 암호화된 파일은 탈취되어도 해당 암호화 알고리즘이 검증된 표준 알고리즘이라면 키(패스워드, 생체..)가 없는 경우 매우 오랜 시간(세대를 걸친..)이 걸릴 가능성이 높습니다. 제 생각에는 파일을 탈취할 수 있을 정도의 권한을 가졌다면 서명 알고리즘을 수행하는 함수를 호출해서 메모리에 평문형태로 키가 올려졌을때 해당 프로세스 메모리를 그대로 덤프해서 키를 찾는것이 더 빠르고 위험한 방법일 것 같아요!
제가 개인키 메모리에 타임아웃을 걸자고 말씀드린 이유는 이런 것이고요.

3번 - 넵! 이제 이해 됐습니다. 말씀하신 key와 나머지 generator, loader, storer의 분리는 저도 동의합니다 :)

[junbeomlee]

@owljoa
궁금한게 암호화 하더라도 우리가 암호화 부분을 숨기는 것이 아니라 이미 코드에 암호화 방법이 나와있기 때문에 복호화는 쉽게 되지 않나요?!! 일반적으로 파일을 암호화하면 그 파일이 탈취되어도 복호화 방법을 모르니까 괜찮은데 우리는 코드상에서 암호화하고 복호화하는 로직이 다 들어있기 때문에 방법과 키가 노출되어서, 이미 노드가 돌아가는 컴퓨터에 접근 가능한 순간에는 어떤 방식으로든 방어가 불가능할 것 같네요..

[owljoa]

@junbeomlee
암호화 알고리즘을 설계할 때 키는 안전하다는 가정으로 설계를 합니다.
암호화 알고리즘의 목적은 키가 없이 복호화를 하려면 브루트 포스로 키를 일일이 대입해봐야 찾을 수 있게 하는것이고요.
그래서 보통 암호화 키는 하드코딩으로 소스내에 포함시키지 않고 사용자가 입력한 패스워드나 생체정보, 사람의 손이 잘 가지 않는 기기들(전봇대, 교통신호 등)의 경우는 하드웨어내에 포함시켜서 코드내에서는 볼 수 없게 하는것이 좋다고 합니다.(실제 이렇게 적용하는지는 저도 잘..;)
이렇게 키가 안전해도 암호문 탈취시 복호화가 가능은 하지만 다항식시간내에는 불가능하도록 만든것이 현대의 암호 알고리즘들이고요.
그래서 브루트포스 공격의 난이도, 즉 안전성은 키의 길이와 연관됩니다.
2048비트의 키를 사용한다면 공격자 입장에서 2의 2048승의 경우를 확인해야합니다. (굉장히 오랜시간..) 이런 경우 지수시간이 걸리고요.

결과적으로는 암호알고리즘이 키의 안전을 가정으로 두다보니 서비스 개발시 가장 핵심은 키관리를 어떻게 해주느냐 입니다. 키관리 솔루션들이 많이 출시되는 이유가 이런 것 때문입니다.

[junbeomlee]

@owljoa
키암호화는 좋은것 같은데 프라이빗 키를 계속 로드해야 되기 때문에 remove key보다는 메모상에서도 암호화를 한다던지 하는 방법이 좋을 것 같은데 이미 프라이빗 노드일 경우 어느정도의 방어막이 구축되어있다고 보는게 맞아서 메모리상에서는 조금 애매한 것 같습니다. 그럼 매번 패스워드를 받아서 실행을 해야하는 거겟죠?

1. 파일 암호화 동의
2. remove 메모리는 너무 자주 사용되기 때문에 매번 로드하는게 더 나을 것 같고
3. 메모리상에서도 암호화가 좋은 것 같습니다.

많은 솔루션들이 클라이언틔 키를 관리하는 것은 존재하는데 피어에서 프라이빗키를 관리하는 다른 체인들을 찾아봐야 더 좋은 해답을 낼 수 있을 것 같습니다.

[junbeomlee]

넵!

[yojkim]

좋은 것 같습니다.

쭉 읽어봤는데 제가 따로 제안해야할 부분은 찾지 못했네요 ㅎㅎ;