API 키와 비밀 키는 어떻게 작동합니까? API 및 비밀 키를 다른 응용 프로그램으로 전달해야하는 경우 안전합니까?

136

API 키와 비밀 키의 작동 방식에 대해 생각하기 시작했습니다. 2 일 전에 Amazon S3에 가입하고 S3Fox 플러그인을 설치했습니다 . 그들은 내게 액세스 키와 비밀 액세스 키를 모두 요청했는데 둘 다 액세스하려면 로그인해야합니다.

그래서 그들이 비밀 키를 요구하는 경우, 어딘가에 키를 저장해야하는지 궁금합니다. 기본적으로 내 신용 카드 번호 또는 비밀번호를 요청하고 자체 데이터베이스에 저장하는 것과 같은 것이 아닙니까?

비밀 키와 API 키는 어떻게 작동합니까? 그들은 얼마나 비밀이되어야합니까? 비밀 키를 사용하는 이러한 응용 프로그램이 비밀 키를 저장하고 있습니까?

— 랜스 폴라드
소스

답변:

여기에 요약 된 내용을 기본적으로 설명 합니다 .

작동 방식은 다음과 같습니다. 0에서 9까지의 숫자를 취하고 3을 더하고 결과가 10보다 큰 경우 10을 빼는 함수가 있다고 가정합니다. f (2) = 5, f (8) = 1 등입니다. 이제 우리는 또 다른 함수를 만들 수 있습니다. f '라고 부르면 3이 아닌 7을 더해서 거꾸로됩니다. f '(5) = 2, f'(1) = 8 등

이것이 양방향 함수와 그 역의 예입니다. 이론적으로, 하나의 것을 다른 것으로 매핑하는 수학 함수는 반대로 될 수 있습니다. 그러나 실제로 입력을 스크램블하여 뒤집기가 매우 어려운 함수를 만들 수 있습니다.

입력을 받고 단방향 함수를 적용하는 것을 입력 "해싱"이라고하며 Amazon이 시스템에 저장하는 것은 비밀 키의 "해시"입니다. SHA1은 이러한 종류의 "단방향"기능의 예이며 공격에 대비하여 강화되었습니다.

HMAC 기능은 텍스트 문자열을 인증하기 위해 알려진 키를 사용하기 위해 설립 해쉬 함수에 구축합니다. 다음과 같이 작동합니다.

요청 텍스트와 비밀 키를 가져 와서 HMAC 기능을 적용하십시오.
해당 인증 헤더를 요청에 추가하고 Amazon으로 보냅니다.
Amazon은 비밀 키 사본과 방금 보낸 텍스트를 찾아 HMAC 기능을 적용합니다.
결과가 일치하면 동일한 비밀 키를 가지고 있다는 것을 알게됩니다.

이 방법과 PKI의 차이점은이 방법이 RESTful 이므로 시스템과 Amazon 서버간에 최소한의 교환이 가능 하다는 것 입니다.

기본적으로 내 신용 카드 번호 또는 비밀번호를 요청하고 자체 데이터베이스에 저장하는 것과 같은 것이 아닙니까?

그렇습니다. 누군가 S3로 할 수있는 피해는 귀하의 계정을 소진하는 것으로 제한됩니다.

그들은 얼마나 비밀이되어야합니까? 비밀 키를 사용하는 이러한 응용 프로그램이 비밀 키를 저장합니까?

어느 시점에서 비밀 키를로드해야하며 대부분의 유닉스 기반 시스템에서는 공격자가 루트 액세스 권한을 얻을 수 있으면 키를 얻을 수 있습니다. 키를 암호화하는 경우 암호를 해독 할 코드가 있어야하며, 어느 시점에서 암호 해독 코드는 일반 텍스트 여야하므로 실행할 수 있습니다. 컴퓨터를 소유하고 있다는 점을 제외하고는 DRM과 동일한 문제입니다.

대부분의 경우 권한이 제한된 파일에 비밀 키를 넣고 시스템이 루팅되지 않도록 일반적인 예방 조치를 취합니다. 임시 파일을 피하는 등 다중 사용자 시스템에서 제대로 작동하게하려면 몇 가지 요령이 있습니다.

— 벤
소스

"입력을 수행하고 단방향 함수를 적용하는 것을 입력"해싱 "이라고하며 시스템에서 Amazon이 저장하는 것은 비밀 키의"해시 "입니다.-Amazon이 비밀 키의 HASH를 저장하는 경우 어떻게됩니까? 아마존이 그들에게 보낸 텍스트를 해쉬 할 수 있습니까?

— Franklin

먼저 "Amazon이 시스템에 저장 한 비밀 키의"해시 "라고 말한 다음"Amazon이 비밀 키의 사본을 찾습니다 "라고 말합니다. 이들은 서로 모순되는 것 같습니다. 나는 첫 번째 진술이 잘못되었다고 생각합니다.

— Sean

이 URL은 Amazon S3 인증 구현에 대한 자세한 내용을 알려줍니다. docs.aws.amazon.com/AmazonS3/latest/dev/S3_Authentication2.html

— asyncwait

"이론적으로, 하나의 것을 다른 것으로 매핑하는 수학적 함수는 반대로 될 수 있습니다."-사실은 아닙니다. 해시 함수가 그 예입니다. 보여주기가 매우 쉽습니다. 값의 합 (a = 1, b = 2, c = 3 등)을 기준으로 단어를 숫자로 변환하는 함수가 있다고 가정하겠습니다. 예를 들어 "SO"는 18 + 14 = 32입니다. 따라서 우리는 SO를 32로 변경했지만이 기능을 누군가에게 공개하고 숫자 32를 주면 기본 단어가 "SO"인지 알 수있는 방법이 없습니다. "ZF"(26 + 6) 또는 수십 가지 다른 가능성

— Leo

@asyncwait가 링크 한 문서에 따르면 Amazon은 비밀 키를 해시뿐만 아니라 확실히 저장합니다. 실제로, 그것은 유일한 해싱이 HMAC 함수 내에서 발생하는 것 같습니다

— cowlinator

공개 키 암호화 는 매우 특정한 공격을 방어하는 데 사용되며 그 중 일부는 일반적입니다. 요컨대 이것은 개인이 공개 키만 알면서 공개 키와 개인 키 쌍을 가지고 있는지 확인할 수있는 복잡한 수학입니다. 이것은 신용 카드 또는 정적 암호와는 매우 다릅니다. 예를 들어 OpenSSH 서버로 인증하는 경우 서버 에 개인 키가 필요하지 않습니다 .

공격 대상이되는 Amazon API 데이터베이스가 공격자에게 공개 키 목록이 있고이 정보를 사용하여 사용자의 API에 액세스 할 수없는 것이 이상적입니다. 그러나 이상적인 시스템이 항상 실행되는 것은 아니며 Amazon 이이 공격 벡터를 막고 있는지 확실하지 않지만 그럴 것입니다.

공개 키 인증에서는 통계적으로 무차별 대입에 영향을받지 않습니다. 암호는 종종 사전에 나오는 단어로, 상대성이 빠르게 깨질 수 있습니다. 그러나 개인 키는 추측하기 어려운 방대한 수입니다. 침입자가 공개 키를 가지고 있다면 슈퍼 컴퓨터에서 많은 "오프라인"추측을 수행 할 수 있지만, 키를 깰 때 많은 시간과 돈이 필요합니다.

— 사기꾼
소스

는 개인 키를 필요로하지 않는다 링크가 깨져 있습니다.

— setzamora

@Joset은 2008 년부터 인터넷 웨이 백 머신에서 복사본을 가리키는 링크를 업데이트했습니다.

— oligofren

AWS는 자체 맞춤형 인증 알고리즘을 설계했습니다. v4는 2014 년에 릴리스되었습니다. 자세한 내용은 여기에 요청 요청 (AWS 서명 버전 4) 이 설명되어 있습니다 . 중요한 점은 요청이 비밀 자체로 서명되지 않고 비밀 키를 사용하여 생성 된 서명 키로 서명된다는 것입니다. 또한 서명에 HMAC-SHA256을 사용합니다.

AWS는 비밀 대신 공개 키만 저장하므로 사용자와 AWS 모두에 의해 저장되므로 비대칭 키를 사용하는 것이 더 안전합니다.

— 바 주크
소스