이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Tink란 무엇인가요?

Tink는 Google의 암호화 전문가 및 보안 엔지니어가 작성한 오픈소스 암호화 라이브러리입니다. Tink의 안전하고 간단한 API는 사용자 중심 설계, 신중한 구현 및 코드 검토, 광범위한 테스트를 통해 일반적인 문제를 줄입니다. Tink가 달성하도록 설계된 목표에 대한 자세한 내용은 이 페이지의 목표 섹션을 참조하세요.

Tink는 암호화 배경이 없는 사용자가 일반적인 암호화 작업을 안전하게 구현할 수 있도록 도와줍니다. Google에서 Tink는 수백 개의 제품과 시스템에 배포되었습니다.

Tink를 사용해야 하는 이유는 무엇인가요?

Tink를 사용하는 가장 중요한 이유는 다음과 같습니다.

간편한 사용

암호화는 제대로 하기가 어렵습니다. Tink를 사용하면 단 몇 줄의 코드로 기본 제공되는 보안 보장 기능을 통해 데이터를 암호화하거나 데이터에 서명할 수 있습니다. 또한 Tink는 외부 키 관리 시스템(KMS)을 사용하여 키 또는 보안 키를 순환하는 데 도움을 줄 수 있습니다.
안전합니다

Tink는 BoringSSL 및 Java 암호화 아키텍처와 같은 잘 알려진 라이브러리에 보안 보호 기능을 추가하고 이를 인터페이스에 바로 표시하므로 감사자와 도구가 신속하게 격차를 찾을 수 있습니다. 또한 Tink는 잠재적으로 위험한 API를 분리하므로 이를 모니터링할 수 있습니다.
이 기능은

Tink 암호문은 기존 암호화 라이브러리와 호환됩니다. 또한 Tink는 Amazon KMS, Google Cloud KMS, Android 키 저장소, iOS 키체인에서의 키 암호화 또는 저장을 지원합니다.

누가 Tink를 사용하나요?

Tink는 Google, Square, Citadel을 비롯한 많은 기업과 수백 명의 Google Cloud 고객과 Google Pay 파트너에서 널리 사용되고 있습니다. 또한 Tink는 Slack, Adidas, AirBnb, Nextdoor와 같은 여러 인기 Android 앱을 보호하는 Jetpack Security 라이브러리를 지원합니다.

Tink 골

다른 암호화 라이브러리와 비교했을 때 Tink의 주요 목표는 무엇이고, Tink가 이러한 목표를 달성하기 위해 사용하는 기본 메커니즘은 무엇인가요?

간단히 말해 Tink의 목표는 두 가지입니다.

암호화 민첩성 향상: 사용자가 간단한 방법으로 키와 알고리즘을 변경할 수 있어야 합니다.
보안 검토 사용 설정: Tink는 명확한 보안을 보장하는 인터페이스를 제공하여 사용자가 로컬에서 보안을 검토할 수 있는 코드를 작성할 수 있도록 하는 것을 목표로 합니다.

Tink에서 이러한 목표를 달성하기 위해 사용하는 주요 메커니즘은 다음과 같습니다.

Tink는 프리미티브와 인터페이스를 중요한 추상화로 제공합니다. 이러한 추상화를 통해 사용자는 사용할 정확한 알고리즘을 지정하지 않고 필요한 보안 개념을 지정하는 코드를 작성할 수 있습니다.
Tink는 특정 프리미티브와 연결된 키 세트인 '키 세트' 개념을 사용합니다. 따라서 사용자는 여러 개의 키로 작동하는 코드를 작성하게 됩니다.
Tink에서 키는 기본 키 자료뿐만 아니라 암호화 알고리즘과 모든 매개변수에 의해서도 지정됩니다. 즉, Tink 키는 항상 존재할 수 있는 모든 기능 중에서 고유한 암호화 함수를 선택하므로 해석할 여지가 없습니다.

다음 섹션에서는 이러한 개념을 더 자세히 설명합니다.

암호화 민첩성

소프트웨어 엔지니어링 분야에서 얻은 교훈을 다룬 서적인 Google의 소프트웨어 공학과 '시간이 지남에 따라 프로그래밍으로 배운 교훈'이라는 부제목을 생각해 보세요. 이 글에서 저자들은 상황이 변한다는 사실의 의미를 간파하기 위해 최선을 다합니다. 이 사실은 Tink 디자인의 많은 부분에도 영향을 미쳤습니다. 암호화에서는 변화에 대비하는 것이 중요합니다. 키가 유출되고 알고리즘이 손상됩니다. 많은 사용자에게 키와 알고리즘을 전환하는 능력이 중요하므로 이를 준비하는 것이 중요합니다.

보안 검토 및 로컬 속성

Tink는 사용자가 데이터를 암호화할 수 있는 AEAD 인터페이스와 같은 인터페이스의 사용을 장려합니다. 다른 보안 보장 중에서도 AEAD는 동일한 문자열의 여러 암호화가 서로 다른 암호문으로 이어진다는 것을 보장합니다.

이 사용 방법을 확인하기 위해 엔지니어가 일부 민감한 ID를 사용자 쿠키에 저장하려고 한다고 가정해 보겠습니다. 다음과 같은 클래스를 제공할 수 있습니다.

class IdEncrypter {
  public static IdEncrypter createFromAead(Aead aead);

  public String encrypt(long id) throws GeneralSecurityException;
  public long decrypt(String encrypted) throws GeneralSecurityException;
};

Aead를 전달하면 다음과 같은 속성이 부여됩니다.

코드는 IdEncrypter가 작업을 실행하려면 Aead가 제공하는 보안 속성이 포함된 암호화 스키마가 필요함을 전달합니다. 또는 DeterministicAead로는 충분하지 않습니다. IdEncrypter에서는 동일한 ID의 두 암호화가 서로 달라야 합니다. 반면 AES GCM 인크립터 인스턴스 (Aead의 특정 인스턴스 하나)를 매개변수로 사용하는 것은 지나치게 엄격합니다. 어떤 Aead라도 IdEncrypter가 작업을 실행하기에 충분하며 하나의 특정 알고리즘이 아니어도 됩니다.
보안 검토는 이 점을 고려할 수 있습니다. 보안 검토자는 누군가가 IdEncrypter와 함께 사용하기에 안전하지 않은 Aead의 서브클래스를 만들었는지 확인하기 위해 전체 코드 저장소를 모두 살펴볼 필요는 없습니다. 대신 Tink는 모든 Aead 객체에 있는 보안 속성을 제공하며, 검토자는 이 속성이 충분한지 확인할 수 있습니다.

특히 두 번째 지점에는 많은 주의가 필요합니다. 사용자는 종종 Aead가 아닌 알고리즘을 추가해 달라고 요청합니다. 앞선 요점에서 이것이 위험한 이유를 설명합니다. 필수 보안 보장을 제공하지 않는 Aead 구현을 사용할 수 있는 경우 IdEncrypter는 안전하지 않을 수 있으며 보안 검토를 실행하는 엔지니어는 추가 코드를 검사하여 객체가 올바르게 인스턴스화되었는지 확인해야 합니다.