참고: [키를 메모리에 오래 두면 위험!] https://stackoverflow.com/questions/7046997/arent-private-keys-vulnerable-in-memory

func zeroBytes(bytes []byte) {
for i := range bytes {
bytes[i] = 0
}
}

이더리움은 이렇게 구현했네요.

이정도만 해두면 서비스 레벨에서 키 사용 시 타이머를 걸어서 이 함수를 실행하거나 하면 될듯합니다!

인증서 검증에 인증서 만료(expired) 여부 체크 기능 추가

type key interface {

}

type priKey interface{
key
}

type pubKey interface{
key
}

로 해주는게 좋을것 같아요. 만약에 prikey에서 pubkey를 얻는다던지 하는 operation들 같은 경우에는 같은 Key interface로는 처리할 수 없기때문에 공통 interface와 개별 interface 를 나눠서 구현해주는것이 더 좋은 방법일것같습니다

InitHeimdall(?)
(설정파일에서 읽어온) 서명키 길이, 사용할 타원곡선, 키 유도 알고리즘 및 유도할 키 길이 등을 입력받아 파라미터 초기 설정하는 함수

설정파일 -> engine - config에... 추가될 예정.

Security Level - 보안 레벨 (표 참고)

KDF(Key Derivation Function) - 키 유도 알고리즘 이름 (키 길이는 보안레벨로부터 유추 가능) ex) pbkdf2, scrypt, bcrypt...
Signing Algorithm - 형식적이지만 서명 알고리즘 ECDSA 명시
Encryption Algorithm - (블록)암호화 알고리즘 - 운영모드 ex) aes-ctr
Certificate Format - 인증서 포멧 ex) pem, der ..
Certificate Path - 인증서 저장 경로
Private Key Path - 개인키 저장 경로

(추가중)
...또 설정 시 추가 필요한 부분 혹시 생각나는거 있으시면 코멘트 부탁드립니다!

scrypt는 n, r, p 값
pbkdf2는 iteration 값

유도되는 키가 private key를 암호화하는데에 쓰이므로 로그인에 쓰이는 키를 유도하는 것보다 안전성 필요

bcrypt 추가

SHA1은 2017년 초에 깨져서 사용하지 않는 것을 권장하고 있습니다.
아직 개인 단위로 깰만한 계산량은 아니지만.. 이론이 아닌 현실에서 가능해졌다는 것은 꽤 위험한 것이 사실이니 사용하지 않는 것이 좋을듯 합니다. :)

references

1. https://shattered.io/
2. http://blog.plura.io/?p=6619

새롭게 패키징된 auth / hashing / key 에 맞춰서 업데이트를 해야함

패스워드 저장할 때 사용하는 scrypt, bcrypt, PBKDF2 중에 하나로 사용해서 구현

@yojkim ㄱ

intermediate CA 인증서는 chain에 꼭 있어야하는 인증서가 아니므로 if문으로 강제해서 에러 발생시키면 root CA에게 직접 받은 정당한 인증서에서 에러 발생

ex) 현재는..
rootCA -> IntermediateCA -> client (정상)
rootCA -> client (에러) -> 이것도 정상이어야함!!

그러므로 cert chain 검증 시 intermediate cert pool의 길이가 0이면 에러 발생시키는 if문 제거해야함!!

코드 수정하다가.. 생각났을때 이슈로 올리는게 좋을것 같아서 올립니다!

에러 메시지나 상수 같은 요소들을 코드내에 직접 입력하지 않고 변수 형태로 특정 dictionary 혹은 definition파일에 저장해서 관리하는건 어떨까요?

go코드에서 어찌 쓸지는 모르지만 예를들면..
PI = 3.14
ERR_NO_OPT = "There is no input option"
이런식으로 만들어두는것이 어떨까요??

1. CRL(Certificate Revocation List)이용해서 인증서의 폐지 여부 확인
2. 인증서내의 생성시간, 만료시간 체크 invalid or expired 확인

구현된 파일들에대해서 테스트를 진행해야함

issue #68 에서 사라진 scrypt parameter들 config에서 사용되는 map형태 param으로 다시 넣기

cert 구현 완료해서 불필요 -> 제거

라이센스 붙이기

키를 사용하고싶은데 사용을 못함.. 인터페이스만 되서..

지금 현재 사용하고 있는 byte 형태
ecdsa의 예로는
private key -> D 값
public key -> curve와 X, Y 좌표 값들을 marshal한 값
을 사용하고 있는데 public chain의 경우는 인증서를 사용하지 않기 때문에 관계가 없지만,,
인증서를 사용하기 위해서는 지켜야할 표준 형태가 있어서.. 이전과 같이 DER, PEM 등의 표준 포멧을 따라야할 것 같습니다.
사실상 표준 포멧들도 코드를 보니 위의 예시처럼 값들을 뽑아서 표준에 맞는 포장을 해주는 거라.. 성능상으로는 별 차이 없을것으로 보입니다.

지금은 ./keyRepository이렇게 되는데 ./heimdall이런게 더 멋지지 않을까여 다들 어캐 생각하시나요?

Pem에서 키를 복구하는 로직이 따로 있어야 할 것 같습니당.

[]byte형태로 pem을 받으면 파일형태가 아니라 []byte만 있음. 이럴때 복구해야되는데 복구하는 함수가 type, []byte를 받아서 해당하는 Key로 반환해주는함수가 있으면 좋겠습니당. 그래야 peer끼리 key교환할 수 있습니다. 도와주세요!!

issue: 인증서 폐기 여부 체크 시, 폐기가 되었는지만 체크하고 안되었을때도 폐기된것으로 false 리턴

=> 폐기가 되었는지 체크 후 폐기된 인증서가 아닌 경우는 true 리턴하도록 수정할 것

노드간 통신 시 신분증명을 위해 rootCA, intermediateCA, 자기자신의 인증서 전송

• 이후에 공개키 이용한 세션 키 교환 후 암호화 통신

0. 인증서 내용
   https://golang.org/pkg/crypto/x509/#Certificate 참고

1. 인증서 store/load 함수 구현

2. 인증서 포멧은 pem, der 지원 (포멧 전환 함수들 구현)

3. keystore와 연계 혹은 keystore내에 구현

4. (미정)

라이브러리 사용자의 입장에서 테스트

👍

kyber/sign/schnorr

변경된 구조에 맞게 readme usage 수정

제가 주로 사용하던 파이썬에서는 아래와 같은 코멘트를 다는 것이 convention이였습니다.
인텔리제이 기반 파이참에서 주석 생성시 함수 원형을 보고 자동으로 저렇게 :param 같은 것들이 만들어집니다.
저런 표준방식의 코멘트가 좋은점은 tool(파이썬의 경우는 sphinx)을 이용한 자동 documentation을 할 때,
편합니다. 그리고 tool까지 안가더라도 코드를 나중에 읽어도 눈에 잘 들어오고요 :)

def load_data(p_user_id: str, target_dir: str, only_user_data: bool=False, fix_user_sample: int=None, fix_imposter_sample: int=None)
-> [np.ndarray, np.ndarray] or np.ndarray:
"""
load legitimate user's data and imposters' data from csv files
:param p_user_id: legitimate user's id(initial)
:param target_dir: target directory for finding requested user data
:param only_user_data: if true, return user data only. if false, return user and imposter data
:param fix_user_sample: fix the number of legitimate user sample to return
:param fix_imposter_sample: fix the number of imposter sample to return
:return: legitimate user data and imposter data
"""

그런데 Go 언어의 convention을 보니 조금 다른것 같네요. golang 개발 깃헙 문서에는 아래와 같은 예시가 있었고, 링크로 가시면 부연설명도 있습니다.(링크 : https://github.com/golang/go/wiki/Comments)
godoc이라는 documentation 자동화 tool도 있네요. (https://godoc.org/)
한글버전의 comment 설명은 (https://golang.kr/doc/effective_go/commentary.html) 에서 조금 볼수 있네요.

// Package superman implements methods for saving the world.
//
// Experience has shown that a small number of procedures can prove
// helpful when attempting to save the world.
package superman

// enterOrbit causes Superman to fly into low Earth orbit, a position
// that presents several possibilities for planet salvation.
func enterOrbit() os.Error {
...
}

coding convention을 일일이 따르는건 나중에 해도 될것 같지만 코멘트나 문서에 대한 규칙(?)은 미리 정의해두어야 좋을것 같아서 말씀드렸습니다!

그래서 아마 제가 달게될 코멘트는 go언어 방식일 것 같습니다 :)

각 Key별로 ToPEM()으로

RSA의 경우
--rsa.go--

func (key *RsaPrivateKey) ToPEM() ([]byte,error) {
keyData := x509.MarshalPKCS1PrivateKey(key.priv)

return pem.EncodeToMemory(
	&pem.Block{
		Type: "RSA PRIVATE KEY",
		Bytes: keyData,
	},
), nil

}

이런식으로 구현 하셨는데,

키 유틸에서도 같은 기능이 구현이 되어 있네요.
--KeyUtils.go--
func PublicKeyToPEM(pub Key) ([]byte, error)
func PrivateKeyToPEM(pri Key) ([]byte, error)

이렇게 같은 기능을 만들어두신 특별한 이유가 있나요??

pbkdf2 추가

이거는 꼭 해야함!!

초기 설정 config를 시작으로 가정하고 사용하던 상수들 config 설정값들로 대체

지금 remove key가 키 파일을 지우는 기능만 하고 있는데,,

private key의 경우엔 필요한 경우에만 메모리에 올리는 것이 안전할것 같아서 어떤 형태로든 메모리에서 private key를 지우는 기능(?)이 명시적으로 필요하지 않을까요?

예를 들면 몇분의 시간을 설정하고 keyManager가 sign이후에 그 시간이 지나면 key를 모두 초기화하거나.. 가장 안전한건 1 sign 1 load겠지만.. 이건 부하가 생길것 같기도 해서요.. :(

Key ID 생성에 대한 내용을 담은
RFC 5280에 이어서 나온 RFC 7093에 따르면

Key ID는 bit string형태의 public key를 SHA(256, 384, 512) 연산 결과의 왼쪽 160bits 사용을 권장하고 있습니다.

bit string형태는 public key의 curve, X, Y좌표를 marshall한 값으로 보입니다.

현재는 그냥 bit string의 SHA256을 사용하고 있습니다.

동작은 문제 없지만 혹시 모를 불상사에 대비해서.. 인증서내에도 SKI가 들어가므로 인증서를 사용하기 위해 표준에 가까운 RFC를 따라가는 것이 좋을 것 같습니다.

지금 버전에 맞게 usage ecdsa로 수정
RSA 제거

1. 각 옵션들의 타입 일체화를 위해 interface를 두고 구현체를 만들었으나.. 고민이 필요

2. key.ID() 하나 때문에 certstore가 hecdsa 패키지로 들어감.. 고민해봐야할 문제

3. key, auth 기능을 패키지로 분리하려면..

1. 키에 get함수를 줘서 직접 필요한 경우에는 pri나 pub키를 이용할 수 있게하거나,
2. wrapping된 키에 바로 접근할 수 있게 대문자 스타트로 해주어야함..
   (적용한다면 전자가 나을것으로 보임)
   고민이 필요

config로 설정 정보 받아서 초기화
cert로 검증

헉. 1번 부분은 더 찾아보니 hyperledger에서도 파일명을 SKI로 사용하는군요..! 하하;

2번 부분만 봐주세요!!

그리고 @yojkim 님께 추가적으로 SKI 관련 질문이 있습니다!
제가 생각한 내용과는 다르게 hyperledger 소스를 보니 private key의 SKI함수에서도 결국은 public key를 바이트 형태로 끌어내서 public key의 SKI를 구하는 것을 확인했습니다.
저희 소스에서 ecdsa는 잘되어있는것 같은데 rsa에서는 public key를 끌어낼때 상수(N:123, E:57)를 사용하게 되어 있는데 이게 어떤 의미가 있는 숫자를 넣으신건가요?

2. 특별한 의미가 없는 숫자라면 private key에 내장된 N, E를 사용하는 것으로 수정하려합니다!

현재는 Simple, Default만 구현되어있으므로
detail한 configuration 가능한 기능 구현

signers := make(map[reflect.Type]signer)
signers[reflect.TypeOf(&key.RSAPrivateKey{})] = &RSASigner{}
signers[reflect.TypeOf(&key.ECDSAPrivateKey{})] = &ECDSASigner{}

디버그를 하다보니 NewAuth function내에 있는 위 코드가 걸려서요.
타입에 따라 다른 종류의 signer를 저장하려는 의도이신건지..
아니면 미리 두 타입 모두의 signer를 초기화하시는 것을 의도하신건지..
궁금합니다!

이유는 위 이미지와 같이 만들어두신 RSA sample로 디버그할때 위 코드를 지나가도 signers 변수에 RSA Signer만 초기화되는것으로 보여서요.