[알아봅시다] OPE 기술의 딜레마 (2013. 10. 1 디지털타임즈)
[알아봅시다] OPE 기술의 딜레마
DB 암호화에 적합… 취약한 안전성은 숙제로
기존 정보 처리연산 과정의 기능저하 문제 극복
색인 뛰어나지만 암호문에 `데이터 순서` 노출
추가적인 장치ㆍ기술로 알고리즘 한계 보완해야
색인 뛰어나지만 암호문에 `데이터 순서` 노출
추가적인 장치ㆍ기술로 알고리즘 한계 보완해야
개인정보를 보호해야 하는 규제가 갈수록 강화되면서 DB암호화가 조명을 받고 있습니다. DB서버에 암호화를 적용하면, DB서버에 저장되는 데이터를 암호화해 저장하고, 데이터를 조회할 때에는 암호화된 데이터를 복호화 한 후 사용자에게 제공합니다. DB서버는 암호화와 복호화를 위한 처리연산을 추가로 수행해야하기 때문에 속도가 떨어질 수밖에 없습니다. DB암호화에서 더 중요한 문제는 검색 색인을 생성하는 문제입니다. 검색 색인은 DB에 저장돼 있는 방대한 데이터 중에서 원하는 데이터를 빠르게 조회하기 위해 사용되는 DB 내부의 추가 정보입니다.암호화된 데이터로부터 원하는 데이터를 검색하려면 암호화가 되기 전의 원본 데이터들을 알아야 하기 때문에 암호화된 데이터를 전부 일일이 복호화해야 합니다.
원하는 데이터를 하나 조회할 때마다 방대한 데이터들을 모두 복호화 해야하기 때문에 엄청난 연산량의 부담이 발생할 수밖에 없겠죠.이같은 암호화 적용으로 인한 DB서버의 성능 저하 문제는 암호화 알고리즘의 효율적인 구현 기술로 해결할 수 있습니다.
그 방법들 중의 하나가 바로 OPE입니다.
데이터를 빠르게 조회하기 위해서는 데이터를 순서대로 정렬을 해두어야 합니다.
가령 수백만명의 주민번호 중에서 내가 찾는 주민등록번호가 포함돼 있는지를 쉽게 찾는 방법은 주민번호를 13자리 자연수로 보고 크기 순서대로 정리해 두는 것입니다. 불행히도 이 방법은 암호화 후에 사용할 수 없습니다.
암호화는 원본 데이터를 예측할 수 없는 임의의 값으로 변환하는 과정이기 때문에 암호화된 데이터는 원본 데이터와는 전혀 다른 순서로 정렬되기 때문이죠.암호화를 적용하더라도 암호된 데이터들이 원본 데이터와 동일한 순서로 정렬될 수 있도록 해주는 방법이 OPE입니다. 크기가 작은 순서로 정렬된 숫자 데이터 1234, 3456, 5678의 세 수가 있다고 가정할 때, 일반적인 암호화를 적용하면 세 수의 암호화된 값들 사이의 순서가 섞이게 됩니다. 하지만 OPE를 적용하면 1234의 암호값이 3456의 암호값보다 앞에 정렬되고, 3456의 암호값은 5678의 암호값보다 앞서게 됩니다.
여기서 한가지 의문점이 생깁니다.
이런 `순서유지’를 하게 되면 `암호화’를 통해 얻으려고 했던 안전한 데이터 보호가 가능할까 하는 점입니다.
안전한 암호화는 암호문으로부터 원본 데이터에 대한 어떤 정보도 얻을 수 없어야 하는데 OPE는 암호문에서 `순서’라는 정보를 얻을 수 있고 이를 바탕으로 평문을 유추할 수 있기 때문이죠.현재 대부분 보안 업체들이 OPE의 안전성을 보완해 줄 기술 및 보안장치를 함께 사용하여 OPE의 취약점을 보완하기 위해 노력하고 있습니다. OPE와 함께 다른 검증받은 암호화 알고리즘을 함께 사용한다거나, 순서정보만을 한번 더 암호화하는 것 등을 그 예로 들 수 있습니다. 그러나 이러한 상황에 대해 잘 알지 못하는 일반인들은 순서유지암호화라는 이름만 믿고 OPE를 다른 암호화 알고리즘처럼 안전성이 뛰어나다고 생각하기 쉽습니다.
OPE기술의 안전성을 과대 포장해 업계의 비난을 산 사례도 있습니다.
따라서 OPE관련 솔루션을 선택할 때에는 제품 내에 OPE의 안전성을 보완해주는 보안장치 및 기술이 있는지를 살펴본 후 제품을 선택해야 합니다.
원하는 데이터를 하나 조회할 때마다 방대한 데이터들을 모두 복호화 해야하기 때문에 엄청난 연산량의 부담이 발생할 수밖에 없겠죠.이같은 암호화 적용으로 인한 DB서버의 성능 저하 문제는 암호화 알고리즘의 효율적인 구현 기술로 해결할 수 있습니다.
그 방법들 중의 하나가 바로 OPE입니다.
데이터를 빠르게 조회하기 위해서는 데이터를 순서대로 정렬을 해두어야 합니다.
가령 수백만명의 주민번호 중에서 내가 찾는 주민등록번호가 포함돼 있는지를 쉽게 찾는 방법은 주민번호를 13자리 자연수로 보고 크기 순서대로 정리해 두는 것입니다. 불행히도 이 방법은 암호화 후에 사용할 수 없습니다.
암호화는 원본 데이터를 예측할 수 없는 임의의 값으로 변환하는 과정이기 때문에 암호화된 데이터는 원본 데이터와는 전혀 다른 순서로 정렬되기 때문이죠.암호화를 적용하더라도 암호된 데이터들이 원본 데이터와 동일한 순서로 정렬될 수 있도록 해주는 방법이 OPE입니다. 크기가 작은 순서로 정렬된 숫자 데이터 1234, 3456, 5678의 세 수가 있다고 가정할 때, 일반적인 암호화를 적용하면 세 수의 암호화된 값들 사이의 순서가 섞이게 됩니다. 하지만 OPE를 적용하면 1234의 암호값이 3456의 암호값보다 앞에 정렬되고, 3456의 암호값은 5678의 암호값보다 앞서게 됩니다.
여기서 한가지 의문점이 생깁니다.
이런 `순서유지’를 하게 되면 `암호화’를 통해 얻으려고 했던 안전한 데이터 보호가 가능할까 하는 점입니다.
안전한 암호화는 암호문으로부터 원본 데이터에 대한 어떤 정보도 얻을 수 없어야 하는데 OPE는 암호문에서 `순서’라는 정보를 얻을 수 있고 이를 바탕으로 평문을 유추할 수 있기 때문이죠.현재 대부분 보안 업체들이 OPE의 안전성을 보완해 줄 기술 및 보안장치를 함께 사용하여 OPE의 취약점을 보완하기 위해 노력하고 있습니다. OPE와 함께 다른 검증받은 암호화 알고리즘을 함께 사용한다거나, 순서정보만을 한번 더 암호화하는 것 등을 그 예로 들 수 있습니다. 그러나 이러한 상황에 대해 잘 알지 못하는 일반인들은 순서유지암호화라는 이름만 믿고 OPE를 다른 암호화 알고리즘처럼 안전성이 뛰어나다고 생각하기 쉽습니다.
OPE기술의 안전성을 과대 포장해 업계의 비난을 산 사례도 있습니다.
따라서 OPE관련 솔루션을 선택할 때에는 제품 내에 OPE의 안전성을 보완해주는 보안장치 및 기술이 있는지를 살펴본 후 제품을 선택해야 합니다.
암호화가 필요한 응용분야는 다양하다.
안전도가 높은 수준으로 요구되는 응용이 있는가하면 안전도가 높지 않아도 괜찮은 응용도 있을 수 있습니다.
OPE의 경우 안전성을 일부 희생하고 성능을 택한 응용이라고 볼 수 있겠죠. OPE는 원본 데이터의 순서가 암호화 후에도 유지된다는 특징이 있기 때문에 데이터 검색 등에서 유용한 기술임에 분명하지만, 안전성에는 한계가 있다는 것을 잊지 말아야 합니다.
보안 업계는 OPE 기술을 적용할 경우, 안정성이 취약한 부분과 정도에 대해서는 사용자에게 정확하게 알려야 하며 사용자는 기존의 블록암호화 알고리즘들과 동일한 수준의 안전한 암호화를 제공하지는 않는다는 것을 이해하고 안전도보다는 성능이 중요한 응용에 선택적으로 적용하도록 해야 합니다.
이와 더불어 부족한 안전도를 보완해 줄 보안장치 및 기능이 제품 내에 탑재돼 있는지를 꼭 검토해야 하는 것도 잊지 말아야합니다.
안전도가 높은 수준으로 요구되는 응용이 있는가하면 안전도가 높지 않아도 괜찮은 응용도 있을 수 있습니다.
OPE의 경우 안전성을 일부 희생하고 성능을 택한 응용이라고 볼 수 있겠죠. OPE는 원본 데이터의 순서가 암호화 후에도 유지된다는 특징이 있기 때문에 데이터 검색 등에서 유용한 기술임에 분명하지만, 안전성에는 한계가 있다는 것을 잊지 말아야 합니다.
보안 업계는 OPE 기술을 적용할 경우, 안정성이 취약한 부분과 정도에 대해서는 사용자에게 정확하게 알려야 하며 사용자는 기존의 블록암호화 알고리즘들과 동일한 수준의 안전한 암호화를 제공하지는 않는다는 것을 이해하고 안전도보다는 성능이 중요한 응용에 선택적으로 적용하도록 해야 합니다.
이와 더불어 부족한 안전도를 보완해 줄 보안장치 및 기능이 제품 내에 탑재돼 있는지를 꼭 검토해야 하는 것도 잊지 말아야합니다.
[기사 원문 보기 – 디지털타임스 http://www.dt.co.kr/contents.htm?article_no=2013100102011860800001]