Percona Server for MySQL: Enhanced Encryption UDFs

 

 

Percona Server for MySQL 8.0.41/8.4.4 에서는 사용자 정의 함수에 다음과 같은 암호화 관련 개선 사항이 도입되었습니다:

  • RSA 암호화/복호화 작업에 RSAES-OAEP (OAEP) 패딩 지원이 추가되었습니다.
  • RSA 서명/검증 작업에 RSASSA-PSS (PSS) 패딩 지원이 추가되었습니다.
  • legacy_padding_scheme 라는 새로운 컴포넌트 시스템 변수가 추가되었습니다.
  • 모든 암호화 UDF 에서 문자 집합 지원이 표준화되었습니다.

mysql

PKCS1 OAEP padding for RSA encrypt/decrypt operations

이제 사용자는 asymmetric_encrypt() 및 asymmetric_decrypt() 함수에서 RSA 알고리즘을 사용할 때 추가 매개변수인 padding 을 지정할 수 있습니다. 이 padding 값은 no, pkcs1, oaep 중 하나일 수 있으며, RSA 이외의 알고리즘에는 지정할 수 없습니다. Padding 이 명시적으로 지정되지 않은 경우, 기본값은 encryption_udf.legacy_padding_scheme 변수의 값에 따라 결정됩니다. 다만, 선택한 패딩 방식에 따라 RSA  알고리즘으로 암호화할 수 있는 메시지 크기에 다음과 같은 제약이 있습니다:

  • no : 메시지 크기는 RSA key 크기와 정확히 같아야 합니다. (예 : RSA 2048 비트의 경우 정확히 256 바이트)
  • pkcs1 : 메시지 크기는 0 에서 RSA 키 크기에서 11을 뺀 값까지 가능해야 합니다. (예 : RSA 2048비트의 경우 0~245 바이트)
  • oaep : 메시지 크기는 0 에서 RSA 키 크기에서 42를 뺀 값까지 가능해야 합니다. (예 : RSA 2048비트의 경우 0~214 바이트)

또한 unicode 문자열을 암호화할 때는 해당 문자열의 바이너리 표현을 사용하므로, 각 문자는 1바이트에서 4바이트까지 차지할 수 있다는 점에 유의해야 합니다. 이러한 추가 바이트들도 최대 메시지 크기 계산에 포함됩니다.

다음은 RSA 2048bit key 와 oaep 암호화 padding 방식을 사용하여 메시지를 암호화하고 복호화하는 방법의 예시입니다.

 

SET @priv_key = create_asymmetric_priv_key('RSA', 2048);

SET @pub_key = create_asymmetric_pub_key('RSA', @priv_key);

SET @message = 'the message we want to encrypt';

SET @encrypted = asymmetric_encrypt('RSA', @message, @pub_key, 'oaep');

SET @decrypted = asymmetric_decrypt('RSA', @encrypted, @priv_key,'oaep');

SELECT CONVERT(@decrypted USING utf8mb4) = @message; -- should return 1

 

 

 

PKCS1 PSS padding for RSA sign / verify operations

이제 사용자는 RSA 알고리즘을 사용할 때 asymmetric_sign() 및 asymmetric_verify() 함수에 추가 매개변수인 padding 을 지정할 수 있습니다. (pkcs1, pkcs1_pss 중 하나) 암호화/복호화 작업과 마찬가지로, RSA 이외의 알고리즘에서는 padding 을 지정해서는 안 되며, 명시적으로 지정하지 않은 경우 기본값은 encryption_udf.legacy_padding_scheme 변수의 값에 따라 결정됩니다.

다음은 RSA 2048bit key 와 pkcs1_pss 서명 padding 방식을 사용하여 간단한 메시지에 대해 계산된 SHA512 해시를 서명하고 검증하는 방법의 예시입니다.

 

SET @priv_key = create_asymmetric_priv_key('RSA', 2048);

SET @pub_key = create_asymmetric_pub_key('RSA', @priv_key);

SET @message = 'the message we want to sign';

SET @digest = create_digest('SHA512', @message);

SET @signature = asymmetric_sign('RSA', @digest, @priv_key, 'SHA512', 'pkcs1_pss');

SELECT asymmetric_verify('RSA', @digest, @signature, @pub_key,'SHA512', 'pkcs1_pss'); -- should return 1

 

 

 

encryption_udf.legacy_padding_scheme component system variable

이전 버전의 Encryption UDFs 컴포넌트와 호환성(이전 버전으로 암호화되거나 서명된 데이터)을 유지하기 위해, encryption_udf.legacy_padding_scheme 이라는 컴포넌트 시스템 변수가 추가되었습니다. 이 변수는 BOOLEAN 타입이며, 기본값은 OFF 입니다. 이 변수의 값은 asymmetric_encrypt(), asymmetric_decrypt(), asymmetric_sign(), asymmetric_verify() 함수에서 padding 매개변수가 명시되지 않았을 때의 동작에 영향을 줍니다.

  • OFF인 경우

asymmetric_encrypt() / asymmetric_decrypt() → oaep 패딩 사용

asymmetric_sign() / asymmetric_verify() → pkcs1_pss 패딩 사용

  • ON인 경우

asymmetric_encrypt() / asymmetric_decrypt() → pkcs1 패딩 사용

asymmetric_sign() / asymmetric_verify() → pkcs1 패딩 사용

이전 버전과 동일한 동작을 원한다면, 이 변수를 ON 으로 설정하면 됩니다. 이렇게 하면 사용자는 padding 매개변수를 명시하지 않아도 자동으로 이전과 동일한 기본값이 적용됩니다.

 

 

Character set normalization for string parameters/return values

이번 버전의 컴포넌트에서는 사용자 정의 함수(UDF)들이 문자열 매개변수 및 반환 값을 처리하는 방식을 개선하여, 이제 문자 집합을 인식하는(charset-aware) 방식으로 동작합니다.

  • Algorithms / digest names / padding 방식 / PEM 형식의 키 및 매개변수는 MySQL 수준에서 함수에 전달되기 전에 자동으로 ascii 문자 집합으로 변환됩니다.
  • Messages / data blocks / 서명 등 해시 계산, 암호화, 복호화, 서명, 검증에 사용되는 데이터는 MySQL 수준에서 함수에 전달되기 전에 자동으로 binary 문자 집합으로 변환됩니다.
  • PEM 형식의 함수 반환값은 ascii 문자 집합으로 할당됩니다.
  • calculating digests / encrypting / decrypting / 서명 작업의 함수 반환값은 binary 문자 집합으로 할당됩니다.

 

 

Conclusion

가장 최근의 보안 모범 사례에 따르면, RSA 에서 권장되는 유일한 패딩 방식 암호화에는 RSAES-OAEP (OAEP), 서명에는 RSASSA-PSS (PSS) 이며, 기존의 RSAES-PKCS1-v1_5 (for encryption) 및 RSASSA-PKCS1-v1_5 (for signing)은 레거시 애플리케이션과의 호환성 목적으로만 사용되어야 한다고 명시되어 있습니다. 따라서 이번 Percona Encryption UDFs 컴포넌트의 추가 사항은 사용자가 최신 암호화 기술을 통해 데이터를 더욱 안전하게 보호할 수 있도록 도와줄 것입니다. 또한 이러한 개선은 조직이나 법적 규제기관에서 요구하는 보안 준수 수준을 충족하는 데에도 기여할 수 있습니다.

또한, 이 블로그 포스트의 예제들은 주로 시연 목적임을 기억해 주세요. 실제 Zero-Trust 환경에서는 생성된 개인 키가 절대로 클라이언트 컴퓨터를 벗어나서는 안 됩니다. 이와 관련된 자세한 내용은 이전 포스트인 “Digital Signatures: Another Layer of Data Protection in Percona Server for MySQL” 에서 확인할 수 있습니다.

 

블로그 원문 : https://www.percona.com/blog/percona-server-for-mysql-enhanced-encryption-udfs/

 

 

자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의:  info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr

Similar Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다