Интернэтийн нууц түлхүүр нь ердөө "4" байв: Глобал CA eMudhra-ийн криптограф сүйрэл ба хөгжүүлэгчдийн авах арга хэмжээ

Интернэтийн аюулгүй байдал бүхэлдээ Public Key Infrastructure (PKI) буюу итгэмжлэгдсэн Certificate Authority (CA)-уудын нууцлал дээр тогтдог. Таны хөтөч, аппликейшн, API дуудалтууд өгөгдлийг нууцлахдаа эдгээр байгууллагуудын гарын үсэг бүхий сертификатад сохроор итгэдэг билээ. Тэгвэл саяхан кибер аюулгүй байдлын түүхэнд гарч байгаагүй хачирхалтай бөгөөд ноцтой криптограф сүйрэл дэлгэгдлээ: Google, Apple, Microsoft, Mozilla-ийн итгэмжлэгдсэн жагсаалтад багтдаг Энэтхэгийн тэргүүлэгч eMudhra CA-ийн 8 завсрын (intermediate) түлхүүрийг энгийн зөөврийн компьютер дээр хэдхэн миллисекундийн дотор тайлж орхив.

Хамгийн цочирдмоор нь: Энэхүү түлхүүрүүдийн нэгнийх нь private key нь ердөө "4" гэсэн тоо байжээ.

"8 битийн итгэлцэл": Компьютер секундийн дотор хэрхэн тайлав?

Elliptic Curve Cryptography (ECC, тодруулбал P-384 муруй) ашиглаж байгаа үед private key $d$ нь 384 битийн асар том, санамсаргүй (random) тоо байх ёстой. Public key $Q$ нь суурь цэг $G$-г хувийн түлхүүр $d$-ээр үржүүлсэнтэй тэнцдэг ($Q = d \times G$). Муруйн дижитал логикийн хувьд $Q$-аас $d$-г буцааж бодож олох нь математикийн хувьд одоогийн тооцооллын хүчин чадлаар боломжгүй (Discrete Logarithm Problem) гэж тооцогддог.

Гэтэл eMudhra-ийн нийтэлсэн сертификатуудын public key дээр аюулгүй байдлын судлаач Google-ийн нээлттэй эхийн paranoid_crypto хэрэгслийг ажиллуулж үзэхэд хачирхалтай үр дүн гарчээ. Сертификатын public key нь $1 \cdot G$, $2 \cdot G$, $3 \cdot G$... гэх мэт бага утгуудыг тооцоолж эхлэхэд л шууд таарч байв.

Илэрсэн 8 түлхүүрийн хувийн утгууд нь бүгд 256-аас бага (өөрөөр хэлбэл ганцхан байт, ердөө 8 бит) байсан бөгөөд тухайлбал 4, 56, 66, 115, 155, 156, 230, 237 байжээ! Тус түлхүүрүүдийг мэдэхийн тулд ямар ч супер компьютер шаардагдаагүй, хөтөч дээрээс хэдхэн мөчлөгт (cycle) brute-force хийж хэдхэн миллисекундэд гаргаж авсан байна.

Хэрэв халдагч энэ түлхүүрийг ашиглавал дэлхийн аль ч домэйн дээр (жишээ нь google.com, bank.com) хуурамч хүчинтэй SSL/TLS сертификат үүсгэж, бүх сүлжээний траффикт Man-in-the-Middle (MitM) халдлага хийх, код гарын үсэг (code-signing) хуурамчаар үйлдэх бүрэн боломжтой болсон гэсэн үг юм.

FIPS Level 3 түвшний HSM яагаад "4" гэсэн тоо гаргав?

Олон нийтийн дунд "Тус байгууллага тоног төхөөрөмж ашиглаагүй, эсвэл хакердуулсан юм биш үү?" гэсэн хардлага гарсан ч бодит шалтгаан нь инженерүүдийн гаргасан ноцтой διαδικторын алдаа (human error) байсныг eMudhra албан ёсоор хүлээн зөвшөөрөв.

Тэд FIPS 140-2 Level 3 стандартын Utimaco брэндийн тусгай Hardware Security Module (HSM) ашиглаж байжээ. Гэвч 2025 оны 4-р сард болсон түлхүүр үүсгэх ёслолын (Key Ceremony) үеэр түлхүүрийг гадаад дата төв рүү экспортлох "key wrap / unwrap" тест хийх нэмэлт скрипт ажиллуулсан байна. Энэхүү тестийн скрпит нь HSM дээр сул түлхүүрүүд (weak keys) давхар үүсгэсэн бөгөөд нэршил (label) нь бараг ижилхэн байснаас шалтгаалан инженерүүд андуурч сул түлхүүрийг сонгон CSR (Certificate Signing Request) үүсгэж, eMudhra root болон Sectigo-оор cross-sign хийлгэжээ!

Энэхүү сүйрлийн хэмжээний алдаа нь бүхэл бүтэн 18 сарын турш, аюулгүй байдлын хоёр ч удаагийн аудит шалгалтыг даван, дэлхийн бүх root store дотор чимээгүй оршин тогтнож байсан нь хамгийн том цочрол боллоо. Улмаар eMudhra компани дэлхийн SSL/TLS зах зээлээс бүрэн гарч буйгаа мэдэгдэж, хувьцаа нь ч огцом унаад байна.

Хөгжүүлэгчид яагаад үүнд анхаарах ёстой вэ?

Google Chrome, Mozilla Firefox, Apple болон Microsoft өнгөрсөн хэдхэн цагийн дотор өөрсдийн root store болон OneCRL/CRLSet механизмаараа тухайн сертификатуудыг блоклож, eMudhra-ийн root сертификатыг итгэмжлэгдсэн жагсаалтаас хаслаа.

Гэвч хөтөч засагдсан ч таны backend дэд бүтэц засагдаагүй байх магадлал маш өндөр байна.

Үүнд:

1. Docker контейнерууд ба Base Images: Таны production дээр ажиллаж буй олон сарын өмнөх хуучин Ubuntu, Alpine, Debian зэрэг Docker image-үүд ca-certificates багцаа автоматаар шинэчилдэггүй. Хэрэв тус container eMudhra root эсвэл Sectigo cross-signed сертификатыг найдвартай гэж үзсэн хэвээр байвал гаднын халдлагад өртөмтгий хэвээр байна.
2. Python (certifi), Go, Node.js орчин: Ихэнх хэлний package болон HTTP client-үүд (жишээ нь Python-ий requests санд суудаг certifi) өөрийн гэсэн CA багцыг хэрэглэдэг. Тэдгээрийг шинэчлээгүй бол систем хуурамч сертификатыг баталгаажуулж эрсдэлд орно.
3. Холболт тасрах (Connection Failures): Хэрэв таны систем эсвэл гуравдагч талын түнш байгууллагын API eMudhra-ийн өртсөн сертификат дээр суурилж байвал орчин үеийн хөтөч болон шинэчлэгдсэн үйлдлийн системүүдээс тухайн API руу хандах холболт "Certificate Untrusted" алдаа заан шууд тасарч эхэлнэ.

Хөгжүүлэгч, DevOps инженерүүдийн хийх алхмууд

• Docker Base Image-үүдээ rebuild хийх: Production болон CI/CD орчны container image-үүд дээрээ apt-get update && apt-get install --only-upgrade ca-certificates (эсвэл тухайн OS-ийн дүйцэх комманд) хийж, баазын сертификатуудаа яаралтай шинэчил.
• Хэлний түвшний CA багцуудыг шинэчлэх: Python хөгжүүлэгчид pip install --upgrade certifi хийх, Go орчинд хамгийн сүүлийн crypto/x509 засварууд орсон хувилбар луу шилжих.
• Дотоод сертификатуудаа шалгах: Хэрэв та өөрийн дэд бүтэц эсвэл IoT төхөөрөмжүүдэд хувийн CA болон түлхүүр үүсгэдэг бол Google-ийн нээлттэй эх google/paranoid_crypto хэрэгслийг ашиглан түлхүүрүүддээ сул энтропи байгаа эсэхийг туршиж үзэх нь зүйтэй.
• HSM болон Key Ceremony-ийн аудит: Тоног төхөөрөмж FIPS баталгаатай байх нь хүний хүчин зүйлээс шалтгаалсан эрсдэлийг хааж чадахгүй гэдгийг eMudhra-ийн кейс тодорхой харууллаа. Key generation скриптүүддээ автоматаар түлхүүрийн энтропиг шалгадаг test assertion оруулахыг зөвлөж байна.

Эх сурвалж:

• Scott Helme: Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds
• Mozilla Bugzilla (Bug 2083449): Private key compromise of eMudhra Intermediate Certificates
• The Hacker News & Red Sift Security Reports