Різниця між java.util.Random і java.security.SecureRandom

Моїй команді передали код із боку сервера (на Java), який генерує випадкові жетони, і у мене є питання щодо того ж -

Мета цих маркерів досить чутлива - використовується для ідентифікатора сесії, скидання пароля і т.д. Маркер "довгий", тому він становить 64 біти.

В даний час код використовує java.util.Randomклас для генерації цих маркерів. Документація для java.util.Randomчітко говориться наступне:

Примірники java.util.Random не є криптографічно захищеними. Розглянемо натомість використовувати SecureRandom, щоб отримати криптографічно захищений генератор псевдовипадкових чисел для використання у відношенні до безпеки додатків.

Тим не менш, спосіб використання коду в даний час java.util.Randomтакий: Він створює екземпляр java.security.SecureRandomкласу, а потім використовує SecureRandom.nextLong()метод для отримання насіння, яке використовується для інстанціювання java.util.Randomкласу. Потім він використовує java.util.Random.nextLong()метод для генерації маркера.

Тож моє запитання зараз - Чи все ще небезпечно, враховуючи те java.util.Random, що насіння використовується насіння java.security.SecureRandom? Чи потрібно змінювати код так, щоб він використовувався java.security.SecureRandomвиключно для генерації лексем?

В даний час кодове насіння є Randomодин раз при запуску

Стандартна реалізація Oracle JDK 7 використовує те, що називається лінійним конгрурентним генератором для отримання випадкових значень у java.util.Random.

Взято з java.util.Randomвихідного коду (JDK 7u2), з коментаря до методу protected int next(int bits), який генерує випадкові значення:

Це генератор лінійних конгрурентних псевдовипадкових чисел, визначений DH Лемер та описаний Дональдом Е. Кнутом у "Мистецтві комп'ютерного програмування", Том 3: Напівлінійні алгоритми , розділ 3.2.1.

Передбачуваність лінійних конгрурентних генераторів

Уго Кравчик написав досить непоганий документ про те, як можна прогнозувати ці ЖКГ ("Як прогнозувати конгруентні генератори"). Якщо вам пощастило та зацікавлено, ви все ще можете знайти в Інтернеті безкоштовну завантажувану його версію. І ще багато досліджень, які наочно показують, що ніколи не слід використовувати ЖКГ у критичних для безпеки цілях. Це також означає, що ваші випадкові номери зараз передбачувані, що вам не потрібно для ідентифікаторів сеансу тощо.

Як зламати лінійний конгрурентний генератор

Припущення про те, що зловмиснику доведеться чекати, коли LCG повториться після повного циклу, є помилковим. Навіть при оптимальному циклі (модуль m у відношенні рецидиву) дуже легко передбачити майбутні значення за набагато менший час, ніж повний цикл. Зрештою, це лише купа модульних рівнянь, які потрібно вирішити, що стає простим, як тільки ви помітили достатню вихідну величину LCG.

Захист не покращується за допомогою «кращого» насіння. Це просто не має значення, якщо ви сіяєте з випадковим значенням, що генерується SecureRandomабо навіть виробляє цінність, прокочуючи штамб кілька разів.

Зловмисник просто обчислить насіння із спостережуваних вихідних значень. Це займає значно менше часу, ніж 2 ^ 48 у випадку java.util.Random. Невіруючі можуть спробувати цей експеримент , де показано, що ви можете передбачити майбутні Randomвиходи, спостерігаючи лише два (!) Вихідні значення в часі приблизно 2 ^ 16. На сучасному комп’ютері не потрібно навіть секунди, щоб передбачити вихід випадкових чисел прямо зараз.

Висновок

Замініть поточний код. Використовуйте SecureRandomвиключно. Тоді принаймні у вас буде невелика гарантія, що результат буде важко передбачити. Якщо ви хочете, щоб властивості криптографічно захищеного PRNG (у вашому випадку це саме те, що вам потрібно), тоді вам доведеться йти SecureRandomлише з цим. Розумний у зміні способу його використання майже завжди призведе до чогось менш безпечного ...

Випадковий має лише 48 біт, де як SecureRandom може мати до 128 біт. Тож шанси повторитись у безпечному випадковості дуже малі.

Випадковий використовує system clockяк насіння / або для генерування насіння. Таким чином, вони можуть бути легко відтворені, якщо зловмисник знає час, в який було створено насіння. Але SecureRandom бере Random Dataу вас os(вони можуть бути інтервалом між натисканнями клавіш і т. Д. - більшість OS збирає ці дані, зберігає їх у файли - /dev/random and /dev/urandom in case of linux/solaris) і використовує це як насіння.
Тож якщо з невеликим розміром токена все добре (у випадку Random), ви можете продовжувати використовувати свій код без будь-яких змін, оскільки ви використовуєте SecureRandom для генерації насіння. Але якщо ви хочете, щоб більші жетони (які не можуть бути піддані brute force attacks) перейдіть із SecureRandom -
У разі необхідності випадкових просто 2^48спроб, з сучасними вдосконаленими процесорами можна розбити це в практичний час. Але для безпечних 2^128спроб знадобляться спроби, на які знадобляться роки і роки, щоб навіть з сучасними сучасними машинами перерватися.

Дивіться це посилання для отримання більш детальної інформації.
EDIT
Після прочитання посилань, наданих @emboss, зрозуміло, що насіння, яким би випадковим воно не було, не повинно використовуватися з java.util.Random. Розрахувати насіння дуже просто, спостерігаючи за виходом.

Перейдіть на SecureRandom - використовуйте Native PRNG (як зазначено у посиланні вище), оскільки /dev/randomдля кожного виклику вони беруть випадкові значення з файлуnextBytes(). Таким чином, зловмисник, що спостерігає за результатами, не зможе зробити нічого, якщо він не контролює вміст /dev/randomфайлу (що дуже малоймовірно)
Алгоритм sha1 prng обчислює насіння лише один раз, і якщо ваш VM працює місяцями, використовуючи той самий Насіння, це може зламатися зловмисником, який пасивно спостерігає за результатами.

ПРИМІТКА - Якщо ви телефонуєте зіткнутися з NATIVE PRNG . У такому випадку використовуйте примірник SHA1 PRNG SecureRandom і кожні кілька хвилин (або деякий інтервал) закладайте цей екземпляр зі значенням відnextBytes()швидше, ніж ваш оператор може вписати випадкові байти (ентропію) у /dev/random, ви можете проблемою під час використання nextBytes()екземпляру NATIVE PRNG SecureRandom. Виконання цих двох паралельно забезпечить регулярне висівання справжніх випадкових значень, а також не вичерпає ентропію, отриману Операційною системою.

Якщо ви два рази запускаєтесь java.util.Random.nextLong()з одним і тим же насінням, воно дасть однакову кількість. З міркувань безпеки ви хочете дотримуватися, java.security.SecureRandomтому що це набагато менш передбачувано.

Ці 2 Класи схожі, я думаю , вам просто потрібно змінити , Randomщоб SecureRandomза допомогою інструменту рефакторінга і більшу частину існуючого коду буде працювати.

Якщо зміна наявного коду є доступною задачею, я пропоную вам використовувати клас SecureRandom, як запропоновано в Javadoc.

Навіть якщо ви виявите, що реалізація класу Random використовує клас SecureRandom внутрішньо. не слід сприймати це як належне, що:

1. Інші реалізації VM роблять те саме.
2. Реалізація класу Random у майбутніх версіях JDK досі використовує клас SecureRandom

Тож кращий вибір - дотримуватися пропозицій щодо документації та прямувати із SecureRandom.

Поточна реалізація посилань java.util.Random.nextLong()робить два виклики до методу, next(int)який безпосередньо піддає 32-бітному поточному насінню:

protected int next(int bits) {
    long nextseed;
    // calculate next seed: ...
    // and store it in the private "seed" field.
    return (int)(nextseed >>> (48 - bits));
}

public long nextLong() {
    // it's okay that the bottom word remains signed.
    return ((long)(next(32)) << 32) + next(32);
}

Верхній 32 біт результату nextLong()- це біти насіння в той час. Оскільки ширина насінини становить 48 біт (каже javadoc), для визначення насіння, яке дало другий 32 біт, достатньо * перебирати інші 16 біт (це всього 65.536 спроб).

Як тільки насіння відомо, всі наступні жетони можна легко обчислити.

Використовуючи висновок nextLong()прямо, частково секрету PNG, настільки, що весь секрет можна обчислити з дуже невеликими зусиллями. Небезпечно!

* Потрібно докласти певних зусиль, якщо другий 32 біт негативний, але це можна дізнатися.

Насіння безглуздо. Хороший випадковий генератор відрізняється обраним початковим номером. Кожен випадковий генератор починається з числа і повторюється через "кільце". Що означає, що ви переходите від одного до іншого числа зі старим внутрішнім значенням. Але через деякий час ви знову доходите до початку і починаєте все спочатку. Отже, ви запускаєте цикли. (повернене значення від випадкового генератора не є внутрішнім значенням)

Якщо ви використовуєте просте число для створення кільця, всі номери в цьому кільці вибираються, перш ніж пройти повний цикл через усі можливі числа. Якщо ви приймаєте непрості числа, вибираються не всі числа, і ви отримуєте коротші цикли.

Більш високі прості числа означають, триваліші цикли, перш ніж знову повернутися до першого елемента. Отже, безпечний випадковий генератор просто має більш тривалий цикл, перш ніж знову доходити до початку, ось чому він безпечніший. Ви не можете передбачити генерацію чисел так просто, як за допомогою коротших циклів.

Іншими словами: Ви повинні замінити всіх.

Я спробую використовувати дуже основні слова, щоб ви могли легко зрозуміти різницю між Random та secureRandom та важливістю класу SecureRandom.

Ніколи не замислюєтеся, як генерується OTP (одноразовий пароль)? Для створення OTP ми також використовуємо Random та SecureRandom. Тепер, щоб зробити ваш OTP міцним, SecureRandom краще, тому що потрібно 2 ^ 128 спроб, щоб зламати OTP, що майже неможливо в теперішній машині, але якщо він використовується Random Class, то ваш OTP може бути зламаний тим, хто може завдати шкоди вашим даним, тому що це потрібно всього 2 ^ 48 спробуй зламати.