SQLite Encryption 기능에 대해 설명한다.
SQLite Library는 public license로 제한없이 무료로 사용할 수 있다.
그러나, 보안성을 만족하기 위해 DB를 암호화 하려면 어떻게 해야 할까?
다음과 같이 2가지 방법이 있을 것이다.
- 필드의 내용을 암호화 하여 DB에 저장하는 방법
이는 매번 저장할때마다 암호화를 수행하고, DB로부터 값을 읽어올때마다
매번 복호화를 해야 한다.
DB를 이용하는 어플레케이션이 많이 복잡해지는 상황이 발생한다.
또한, 모든 필드를 각각 암/복호화를 해야 하기 때문에 동작 시간이 많이 늘어나게 된다.
- DB 파일 자체를 암호화 하는 방법
DB 파일을 암호화 하는 것은 위의 방식보다는 간편하다.
그러나, DB 파일 자체가 크면 암/복호화 하는 시간이 많이 걸릴것이다.
또한, DB 파일을 암호화 하는 시점이 애매하다.
정상적인 프로그램 종료시 암호화를 하여 저장한다면, 비 정상적으로 종료되는
상황에서는 DB에 최신정보를 유지할 수가 없게 된다.
위의 2가지 암호화 방식은 상기와 같은 문제점이 있어, 그리 올바른 프로그램 방식이
아니다.
이에, SQLite에서는 암호화를 지원하기 위한 Extension 기능을 제공한다.
이를 SQLite Encryption Extension(이하에서는 SEE라고 명칭)이라고 한다.
SEE는 무료인가?
아니다, 2,000 달러를 지불해야 구매가 가능하다.
2,000 달러를 입금하면, SEE 소스를 다운받을 수 있는 id, password를 받을 수 있다.
소스를 다운받는 사이트는 아래와 같다.
https://www.sqlite.org/see/doc/release/www/index.wiki
직접 2,000 달러를 주고 구매해 보았다.
id, password를 받고 위 사이트에 로그인하니 SEE 소스를 다운받을 수 있었다.
2019.07.20일 기준으로 stable, release 버전은 다음과 같다.
stable: SQLIte 3.7.17 버전을 기준으로 만든 SEE 소스
release: SQLIte 3.29.0 버전을 기준으로 만든 SEE 소스
나는 stable 버전이 안정적이기에 이를 다운받아 사용하였다.
SEE compile 방법:
- SEE 소스를 다운받는다.
여기에는 sqlite.c, see.c 등의 파일이 있다.
- SEE 소스 compile
sqlite.c, see.c 등의 파일을 CL 명령어를 통해서 컴파일 한다.
- 컴파일된 파일을 static library로 생성
sqlite.lib로 생성한다.
SEE 기능 적용방법:
- 위에서 생성한 sqlite.lib를 응용 어플리케이션에서 import 한다.
Visual Studio 사용자라면, Link에서 종속 library로 sqlite.lib를 추가한다.
- 다음 함수를 통해서 암호화 key 설정한다.(SQLite 3.7.17 stable 버전 기준)
SQLITE_API int sqlite3_key( sqlite3 *db,
const void *pKey,
int nKey );
위의 pKey에 암호화를 위한 Key를 입력하면 된다.
aes128 암화화 하는 경우: aes128:1234567890123456
aes256 암화화 하는 경우: aes256:12345678901234561234567890123456
위에서 보는바와 같이 prefix로 "aes128:" or "aes256:"을 기입하고,
aes128인 경우는 16바이트, aes256인 경우는 32바이트 키를 넣어주면 된다.
SEE 속도 테스트 결과:
무엇보다 중요한것이 암호화하면 속도가 얼마나 느려지는가 이다.
이에 SEE 수행속도를 간략하게나마 테스트 해보았다.
시스템 조건:
cpu: Inter Core i7-8550U CPU 1.80GHz 1.99 GHz
memroy: 8GB
저장장치: SSD
저장장치: SSD
데이터 조건
table: 100개
table 당 레코드 수: 1000개
table의 column 구조: 5개 INTEGER, 4개 TEXT, 1개 BLOB
column 내용: 4개 TEXT에는 50바이트의 문자열, 1개 BLOB에는 256바이트 blob
SEE 수행 테스트 결과:
- SEE 적용버전(aes128 형식으로 암호화)
table에 1000개의 레코드 insert 소요시간: 평균 15 second
where절을 이용한 900개의 레코드 update 시간: 0 second
where절을 이용한 900개의 레코드 delete 시간: 0 second
where절을 이용한 900개의 레코드 query 시간: 0 second
- SEE 미적용 버전(암호화를 하지 않은 경우)
table에 1000개의 레코드 insert 소요시간: 평균 15 second
where절을 이용한 900개의 레코드 update 시간: 0 second
where절을 이용한 900개의 레코드 delete 시간: 0 second
where절을 이용한 900개의 레코드 query 시간: 0 second
SEE 수행결과에 따른 결론:
위 테스트 조건에서는 SEE 적용에 따른 속도 저하가 나타나지 않았다.
SEE 적용 알고리즘이 최적화 되었다고 하니, 이렇게 속도가 느려지지 않은것 같다.
앞으로는 더 대용량의 조건을 가지고 테스트 해봐야 겠다.
위 내용은 개인적으로 검토한 내용이므로 참고만 하시기 바랍니다.
감사합니다.