Linux: 잠금 풀 제거 /dev/random

암호화된 보안 의사 난수 생성기(CSPRNG)인 /dev/random에는 차단이라는 한 가지 성가신 문제가 있는 것으로 알려져 있습니다. 이 기사에서는 이를 해결하는 방법을 설명합니다.

지난 몇 달 동안 커널의 난수 생성 기능이 약간 재작업되었지만 이 하위 시스템의 문제는 더 넓은 범위에서 해결되었습니다. 기간. 제일 마지막 변경 사항 시스템 부팅 시 getrandom() 시스템 호출이 오랫동안 차단되는 것을 방지하기 위해 만들어졌지만, 그 근본적인 이유는 Random Pool의 차단 동작 때문이었습니다. 최근 패치에서는 이 풀이 제거되었으며 메인 코어로 향할 것으로 예상되었습니다.

Andy Lutomirski는 XNUMX월 말에 패치의 세 번째 버전을 게시했습니다. 그는 기여한다 "임의의 Linux API에 대한 두 가지 주요 의미 변경". 패치는 getrandom() 시스템 호출에 새로운 GRND_INSECURE 플래그를 추가합니다(Lutomirsky는 이를 고정 플래그와 함께 getrandom()을 사용하여 glibc에서 구현되는 getentropy()라고 지칭하지만). 이 플래그를 사용하면 호출 시 항상 요청된 데이터 양을 반환하지만 데이터가 무작위라는 보장은 없습니다. 커널은 주어진 시간에 가장 좋은 무작위 데이터를 생성하기 위해 최선을 다할 것입니다. "아마도 가장 좋은 방법은 '안전하지 않음'이라고 부르는 것입니다. (안전하지 않음) 이 API가 보안이 필요한 용도로 사용되는 것을 방지합니다."

패치는 차단 풀도 제거합니다. 커널은 현재 두 개의 무작위 데이터 풀을 유지 관리합니다. 하나는 /dev/random에 해당하고 다른 하나는 /dev/urandom에 해당합니다. 기사 2015. 차단 풀은 /dev/random에 대한 풀입니다. 해당 장치에 대한 읽기는 요청을 충족하기에 "충분한" 엔트로피가 시스템에서 수집될 때까지 차단됩니다(즉, 해당 이름을 의미함). 풀에 엔트로피가 충분하지 않으면 이 파일의 추가 읽기도 차단됩니다.

잠금 풀을 제거한다는 것은 /dev/random에서 읽는 것이 플래그가 0으로 설정된 getrandom()처럼 동작한다는 것을 의미합니다(그리고 GRND_RANDOM 플래그를 noop으로 바꿉니다). CRNG(암호화 난수 생성기)가 초기화되면 /dev/random에서 읽고 getrandom(...,XNUMX)을 호출하면 차단되지 않고 요청된 양의 무작위 데이터가 반환됩니다.

루토미르스키는 이렇게 말합니다. “저는 Linux 차단 풀이 더 이상 사용되지 않는다고 생각합니다. CRNG Linux는 키 생성에도 사용할 수 있을 만큼 충분한 출력을 생성합니다. 차단 풀은 물질적인 의미에서 더 강력하지 않으며 이를 지원하려면 가치가 모호한 인프라가 많이 필요합니다.”

이러한 변경은 기존 프로그램이 실제로 영향을 받지 않도록 하고 실제로 GnuPG 키 생성과 같은 작업을 오래 기다려야 하는 문제를 줄이겠다는 목표로 이루어졌습니다.

“이러한 에피소드는 기존 프로그램을 방해해서는 안 됩니다. /dev/urandom은 변경되지 않습니다. /dev/random은 여전히 ​​부팅 시 즉시 차단되지만 이전보다 차단 횟수가 적습니다. 기존 플래그를 사용하는 getentropy()는 이전과 마찬가지로 실제 목적에 적합한 결과를 반환합니다."

Lutomirsky는 커널이 차단 커널이 어느 정도 수행해야 했던 소위 "진정한 난수"를 제공해야 하는지 여부는 여전히 공개된 질문이라고 지적했습니다. 그는 이에 대한 단 하나의 이유, 즉 "정부 표준 준수"를 봅니다. Lutomirsky는 커널이 이를 제공하려면 완전히 다른 인터페이스를 통해 수행하거나 사용자 공간으로 이동하여 사용자가 이러한 잠금 풀을 생성하는 데 사용할 수 있는 원시 이벤트 샘플을 검색할 수 있도록 해야 한다고 제안했습니다.

스테판 뮐러(Stephan Müller)는 자신의 세트를 제안했습니다. 패치 Linux용 LRNG(Random Number Generator)(현재 버전 26 출시)는 이를 필요로 하는 애플리케이션에 진정한 난수를 제공하는 방법이 될 수 있습니다. LRNG는 "임의의 비트를 생성하는 데 사용되는 엔트로피 소스에 대한 SP800-90B 지침을 완전히 준수"하여 정부 표준 문제에 대한 솔루션을 제공합니다.
Matthew Garrett은 "진정한 무작위 데이터"라는 용어에 반대하며 샘플링된 장치는 원칙적으로 예측할 수 있을 만큼 정확하게 모델링될 수 있다고 지적했습니다. "우리는 여기서 양자 이벤트를 샘플링하지 않습니다."

Müller는 이 용어가 "기본 노이즈 소스가 엔트로피를 생성하는 것과 동일한 속도로" 결과를 생성하는 난수 생성기를 설명하기 위해 독일 표준 AIS 31에서 유래했다고 응답했습니다.

용어 차이는 제쳐두고, LRNG 패치에서 제안한 대로 잠금 풀을 사용하면 최소한 권한 없이 액세스하는 경우 다양한 문제가 발생할 수 있습니다.

Lutomirsky가 말했듯이 : “이것은 문제를 해결하지 못합니다. 두 명의 다른 사용자가 gnupg와 같은 어리석은 프로그램을 실행하면 서로를 소모하게 됩니다. 나는 현재 /dev/random에 두 가지 주요 문제가 있음을 확인했습니다. DoS(예: 리소스 고갈, 악의적인 영향 또는 이와 유사한 것)에 취약하고, 이를 사용하는 데 권한이 필요하지 않기 때문에 남용되기 쉽습니다. Gnupg가 잘못되었습니다. 완전히 붕괴되었습니다. gnupg 및 유사한 프로그램이 사용할 권한이 없는 새로운 인터페이스를 추가하면 우리는 또 다시 패배하게 될 것입니다."

Mueller는 getrandom()을 추가하면 이제 GnuPG가 이 인터페이스를 사용할 수 있게 되었다고 언급했습니다. 왜냐하면 풀이 초기화되었다는 필수 보장을 제공하기 때문입니다. GnuPG 개발자 Werner Koch와의 논의를 바탕으로 Mueller는 보증이 GnuPG가 현재 /dev/random에서 직접 읽는 유일한 이유라고 믿습니다. 그러나 서비스 거부(오늘날의 /dev/random처럼)에 취약한 권한 없는 인터페이스가 있는 경우 Lutomirsky는 일부 애플리케이션에서 해당 인터페이스가 오용될 것이라고 주장합니다.

Linux의 난수 하위 시스템 개발자인 Theodore Yue Tak Ts'o는 차단 풀의 필요성에 대해 마음을 바꾼 것으로 보입니다. 그는 이 풀을 제거하면 Linux에 진정한 난수 생성기(TRNG)가 있다는 생각이 효과적으로 제거될 것이라고 말했습니다. "이것은 말도 안되는 일이 아닙니다. 왜냐하면 이것이 바로 *BSD가 항상 해왔던 일이기 때문입니다."

그는 또한 TRNG 메커니즘을 제공하는 것이 응용 프로그램 개발자에게 단순히 미끼 역할을 할 것이라고 우려하고 있으며 실제로 Linux가 지원하는 다양한 유형의 하드웨어를 고려할 때 커널에서 TRNG를 보장하는 것은 불가능하다고 믿습니다. 루트 권한으로만 장비를 사용하는 기능으로도 문제가 해결되지 않습니다. "응용 프로그램 개발자는 보안 목적으로 자신의 응용 프로그램을 루트로 설치하도록 지정하므로 이것이 '정말 좋은' 난수에 액세스할 수 있는 유일한 방법입니다."

Mueller는 Cao가 자신이 오랫동안 제안했던 차단 풀 구현을 포기했는지 물었습니다. Cao는 Lutomirsky의 패치를 사용할 계획이며 차단 인터페이스를 커널에 다시 추가하는 것에 적극적으로 반대한다고 응답했습니다.

“커널은 노이즈 소스가 적절하게 특성화되었는지 여부를 보장할 수 없습니다. GPG 또는 OpenSSL 개발자가 얻을 수 있는 유일한 것은 TRUERANDOM이 "더 좋다"는 막연한 느낌이며, 더 많은 보안을 원하기 때문에 의심할 여지 없이 TRUERANDOM을 사용하려고 노력할 것입니다. 어느 시점에서는 차단될 것이고, 다른 똑똑한 사용자(아마도 배포 전문가)가 이를 init 스크립트에 삽입하고 시스템 작동이 중지되면 사용자는 Linus Torvalds에게 직접 불평하면 됩니다.”

Cao는 또한 암호 작성자와 실제로 TRNG가 필요한 사람들에게 적합하다고 판단되는 대로 사용할 수 있도록 사용자 공간에서 자신의 엔트로피를 수확할 수 있는 방법을 제공하는 것을 옹호합니다. 그는 엔트로피 수집은 지원하는 모든 하드웨어에서 커널이 수행할 수 있는 프로세스가 아니며 커널 자체가 다양한 소스에서 제공되는 엔트로피의 양을 추정할 수 없다고 말합니다.

"커널은 서로 다른 노이즈 소스를 함께 혼합해서는 안 되며, 터무니없이 단순한 CPU에서 일종의 "트위치 엔트로피 게임"을 플레이하려고 할 때 얼마나 많은 엔트로피 비트를 얻는지 알고 있다고 주장해서는 안 됩니다. 소비자 사용자를 위한 아키텍처 모든 것이 단일 마스터 오실레이터와 동기화되지 않는 IOT/임베디드 사례, 레지스터 순서를 바꾸거나 이름을 바꾸는 CPU 명령이 없는 경우 등입니다."

“이러한 계산을 수행하는 도구를 제공하는 것에 대해 이야기할 수 있지만 이러한 작업은 각 사용자의 하드웨어에서 수행되어야 하며 이는 대부분의 배포 사용자에게 실용적이지 않습니다. 이것이 암호 작성자만을 위한 것이라면 그들의 사용자 공간에서 수행되도록 하십시오. 그리고 GPG, OpenSSL 등을 단순화하여 모두가 "우리는 "진정한 무작위성"을 원하고 그 이하에 안주하지 않을 것입니다."라고 말하도록 해서는 안 됩니다. 우리는 암호 작성자에게 인터페이스를 제공하여 분리되고 명명된 주요 소음원에 액세스하여 필요한 정보를 얻을 수 있도록 하는 방법에 대해 이야기할 수 있으며, 아마도 소음원은 라이브러리나 사용자 공간 응용 프로그램에 대해 스스로 인증할 수 있습니다."

예를 들어 일부 이벤트에 보안 영향이 있을 수 있기 때문에 이러한 인터페이스가 어떤 모습일지에 대한 논의가 있었습니다. Cao는 키보드 스캔 코드(예: 키 입력)가 엔트로피 수집의 일부로 풀에 혼합되어 있다고 지적했습니다. "권한 있는 시스템 호출을 통해서라도 이를 사용자 공간으로 가져오는 것은 아무리 말해도 현명하지 못할 것입니다." 다른 이벤트 타이밍으로 인해 사이드 채널을 통해 일종의 정보 유출이 발생할 가능성이 높습니다.

따라서 Linux의 난수 하위 시스템과 관련된 오랜 문제가 해결되는 과정에 있는 것 같습니다. 난수 하위 시스템이 최근에 겪은 변경으로 인해 실제로는 이를 사용하는 동안 DoS 문제만 발생했습니다. 이제 커널이 제공할 수 있는 최상의 난수를 얻는 효율적인 방법이 있습니다. Linux에서 TRNG가 여전히 바람직하다면 이 결함은 향후에 해결되어야 하지만 커널 자체 내에서는 해결되지 않을 가능성이 높습니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com