Както е известно, в /dev/random, криптографски сигурния генератор на псевдослучайни числа (CSPRNG), има един неприятен проблем - блокиране. В тази статия се описва как може да бъде решен.
През последните няколко месеца средствата за генериране на случайни числа в ядрото бяха малко преправени, но проблемите в тази подсистема се решават в по-широки Най- бяха направени с цел да се предотврати дългото блокиране на системния вызов getrandom() по време на зареждане на системата, но причината за това беше поведението на блокиращия пул за случайни числа. Наскоро патчът премахна този пул и се очакваше той да бъде включен в основното ядро.
Енди Лутомирски (Andy Lutomirski) публикува третата версия на патча в края на декември. Той внася «две основни семантични промени в API-тата за случайни числа на Linux». Патчът добавя нов флаг GRND_INSECURE към системния вызов getrandom() (въпреки че Лутомирски го нарича getentropy(), който се реализира в glibc с помощта на getrandom() с фиксирани флагове); този флаг принуждава вызова винаги да връща изискваното количество данни, но без гаранция, че тези данни са случайни. Ядрото просто ще положи всички усилия, за да предостави най-добрите случайни данни, които има в момента. «Вероятно, най-доброто, което може да се направи, е да се нарече „INSECURE“ (несигурен), за да се предотврати използването на това API за неща, изискващи сигурност».
Патчовете също така премахват блокиращия пул. В момента ядрото поддържа два пула случайни данни, единият от които съответства на /dev/random, а другият - на /dev/urandom, както е описано в тази 2015 година. Блокиращият пул е пул за /dev/random; четенето от това устройство ще бъде блокирано (имайки предвид името му) до момента, в който от системата не бъде събрана „достатъчна“ ентропия, за да задоволи заявката. По-нататъшните четения от този файл също се блокират, ако в пула няма достатъчно ентропия.
Премахването на блокиращия пул означава, че четенето от /dev/random се държи като getrandom() с нулеви флагове (и превръща флага GRND_RANDOM в noop). След инициализация на криптографския генератор на случайни числа (CRNG), четенето от /dev/random и повикванията на getrandom(…,0) няма да блокират и ще върнат поискания брой случайни данни.
Лутомирски казва: „Смятам, че блокиращият пул на Linux е остарял. CRNG на Linux генерира изходни данни, които са достатъчно добри, за да ги използват дори за генериране на ключове. Блокиращият пул вече не е по-силен в нито един материален смисъл, а за поддръжката му е необходима много инфраструктура с съмнителна стойност.“
Промените бяха направени с цел съществуващите програми да не пострадат, а всъщност проблемите с дългото чакане на такива неща, като генерирането на ключове GnuPG, ще станат по-малко.
„Тези серии не трябва да нарушават никакви съществуващи програми. /dev/urandom остава непроменен. /dev/random все още блокира веднага след зареждане, но блокира по-малко от преди. getentropy() с текущите флагове ще върне резултат, който ще бъде толкова подходящ за практически цели, колкото и преди.“
Лутомирски отбеляза, че все още остава отворен въпросът дали ядрото трябва да предоставя така наречените „истински случайни числа“, което до известна степен е трябвало да прави блокиращото ядро. Той вижда само една причина за това: „да се отговаря на държавните стандарти“. Лутомирски предположи, че ако ядрото наистина трябва да осигури това, то трябва да стане чрез напълно различен интерфейс или да бъде пренесено в пространството на потребителя, предоставяйки му възможност да извлече необработени проби от събития, които могат да бъдат използвани за създаване на такъв блокиращ пул.
Штефан Мюллер (Stephan Müller) предположи, че неговият набор Генератор случайных чисел для Linux (LRNG) (в настоящее время выпущена 26 версия) может предоставить истинные случайные числа для приложений, которым это необходимо. LRNG «полностью соответствует требованиям Рекомендаций по источникам энтропии, используемым для генерации случайных битов» SP800-90B», что делает его решением по стандартам государства.
Мэтью Гарретт возразил против термина «истинные случайные данные», подчеркивая, что устройства, выбираемые в принципе, могут быть смоделированы достаточно точно, чтобы стать предсказуемыми: «мы не выбираем квантовые события».
Мюллер ответил, что этот термин произошел от немецкого стандарта AIS 31 для описания генераторов случайных чисел, которые выдают результат «с такой же скоростью, с какой базовый источник шума производит энтропию».
Помимо различий в терминологии, наличие пула блокировки, как это предполагается патчами LRNG, приведет к различным проблемам, по крайней мере, если к нему будет доступ без привилегий.
Как сказал Лутомирский: «Это не решает проблему. Если два разных пользователя запускают нежелательные программы, такие как gnupg, они просто истощат ресурсы друг друга. Я вижу, что в настоящее время есть две основные проблемы с /dev/random: он подвержен DoS (то есть истощению ресурсов, вредоносному воздействию или подобному), и поскольку его использование не требует привилегий, он также склонен к злоупотреблениям. Gnupg — это неверное решение, это полный провал. Если мы добавим новый непривилегированный интерфейс для использования gnupg и подобных программ, мы снова ошибемся».
Мюллер отметил, что добавление getrandom() теперь позволит GnuPG использовать этот интерфейс, поскольку он обеспечит необходимую гарантию того, что пул был инициализирован. На основе дискуссий с разработчиком GnuPG Вернером Кохом, Мюллер считает, что эта гарантия — единственная причина, по которой GnuPG в настоящее время читает напрямую из /dev/random. Но если имеется непривилегированный интерфейс, подверженный отказу в обслуживании (как в случае с /dev/random), то, по утверждению Лутомирского, он будет использоваться неправильно некоторыми приложениями.
Теодор Цао (Theodore Yue Tak Ts’o), разработчик подсистемы случайных чисел Linux, очевидно, изменил свое мнение по поводу нужды в блокирующем пуле. Он заявил, что удаление этого пула поможет устранить мнение о том, что Linux имеет настоящий генератор случайных чисел (TRNG): «это не бессмысленно, ведь именно это всегда делали *BSD».
Он также обеспокоен тем, что предоставление механизма TRNG станет лишь приманкой для разработчиков приложений и считает, что на самом деле из-за различных типов аппаратного обеспечения, поддерживаемого Linux, невозможно гарантировать наличие TRNG в ядре. Проблему не решит даже возможность работы с оборудованием только с привилегиями root: «Разработчики приложений указывают, что их приложение в целях безопасности должно быть установлено как root, только так вы можете получить доступ к «действительно хорошим» случайным числам».
Мюллер спросил, не отказался ли Цао от реализации блокирующего пула, который он сам предложил давно. Цао ответил, что планирует взять патчи Лутомирского и активно противится добавлению блокирующего интерфейса обратно в ядро.
«Ядро не может дать никаких гарантий по поводу того, был ли noise source должным образом охарактеризован. Единственное, что может получить разработчик GPG или OpenSSL — это неясное чувство, что TRUERANDOM «лучше», и поскольку они хотят большей безопасности, несомненно, попытаются его использовать. В какой-то момент он заблокируется, и когда какой-либо другой умный пользователь (возможно, специалист по выпуску дистрибутива) вставит его в init скрипт, системы перестанут работать, и пользователям останется только жаловаться самому Линусу Торвальдсу».
Цао также настаивает на том, чтобы предоставить криптографам и тем, кто действительно нуждается в TRNG, возможность собирать свою собственную энтропию в пользовательском пространстве для использования по своему усмотрению. Он утверждает, что сбор энтропии — это не тот процесс, который может выполнять ядро на всевозможных поддерживаемых им аппаратных средствах, кроме того, само ядро не может оценить количество энтропии, обеспечиваемое различными источниками.
Ядро не трябва да смесва различни noise source, и разбира се, не трябва да се опитва да твърди, че знае колко бита ентропия получава, когато се опитва да играе на някаква „раздърпана игра на ентропия“ на простичка до безобразие архитектура CPU за потребителски случаи IoT/Embedded, когато всичко е разсинхронизирано с единствен генератор на основно време, когато няма никаква инструкция на CPU за пренареждане или преименуване на регистър и т.н.
Може да се говори за предоставяне на инструменти, които се опитват да направят тези изчисления, но такива неща трябва да се извършват на оборудването на всеки потребител, което за повечето потребители на дистрибуцията е просто непрактично. Ако обаче това е предназначено само за криптографи, нека бъде направено в тяхното потребителско пространство. И да не опростяваме GPG, OpenSSL и т.н., така че всички да казват: „искаме „истинска случайност“ и не се съгласваме на по-малко“. Можем да говорим за това как предоставяме интерфейси на криптографите, за да могат да получат необходимата информация чрез достъп до първични noise sources, отделени и поименувани, и, възможно е, по някакъв начин noise source да може да се аутентифицира в библиотеката или приложението на потребителското пространство.
Имало е малка дискусия относно това как може да изглежда такъв интерфейс, тъй като, например, за някои събития могат да имат последствия в отношение на сигурността. Цао отбеляза, че кодовете за сканиране на клавиатурата (т.е. натискания на клавиши) се смесват в пул като част от събирането на ентропия: „Примесването на това в потребителското пространство, дори чрез привилегирано системно извикване, би било, най-малкото, неразумно“. Напълно е възможно и други времеви събития да създадат някаква информация по странични канали.
Така се създава усещането, че дългогодишният проблем на подсистемата за случайни числа в Linux е на път да бъде решен. Промените, през които подсистемата за случайни числа премина напоследък, всъщност водеха само до проблеми с DoS в процеса на нейното използване. Сега обаче, се появиха ефективни начини за получаване на най-добрите случайни числа, които ядрото може да предостави. Ако все пак TRNG все още е желателен за Linux, този недостатък трябва да бъде отстранен в бъдеще, но е малко вероятно да се направи вътре в самото ядро.
Малко реклама 🙂
Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, , уникален аналог на entry-level сървъри, който е създаден от нас за вас: (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това
Източник: habr.com
