ПРИЛОЖНА КРИПТОГРАФИЯ

[Avatara]

Съвременната приложна крипптография е изключително динамично развиваща се наука.

Това, което ме радва е, че през последните години в рамките на една от най-големите инженерингови структури, работещи в това направления, малка група от български колеги, успяха да постигнат забележителни резултати. 

Желанието ми е в тази тема да разгледаме конкретни казуси, имащи непосредствено отношение към практическата криптография. 

Това, с което ще започнем е какво са крипто примитивите (crypto primitives), каква е разликата между "посоляване" (salt) и "посявка" (seed) и защо често се бъркат, за какво се използват "маските"  (mask generation function, MGF) и по какво се отличават от "хеш функциите" (hash function), какво е key derivation function (KDF) и каква е връзката му с NIST Special Publication 800-132,  ще поговорим за това, защо е нужно да познаваме в детайли SP 800-90A, SP 800-90B и SP 800-90C, както и други стандарти, имащи непосредствено отношени към темата.

Надявам се в размките на дискусията да успеем да съхраним добрия тон и професионалната етика.

Ще се радвам ако мога да отговоря на конкретни въпроси, но държа да подчертая, че познанията ми са ограничени в много тясна и специфична сфера.

С уважение към всички, които биха проявили интерес.

Avatara

 

[Кит]

преди 1 час, Avatara каза:

Съвременната приложна крипптография е изключително динамично развиваща се наука.

Това, което ме радва е, че през последните години в рамките на една от най-големите инженерингови структури, работещи в това направления, малка група от български колеги, успяха да постигнат забележителни резултати. 

Желанието ми е в тази тема да разгледаме конкретни казуси, имащи непосредствено отношение към практическата криптография. 

Това, с което ще започнем е какво са крипто примитивите (crypto primitives), каква е разликата между "посоляване" (salt) и "посявка" (seed) и защо често се бъркат, за какво се използват "маските"  (mask generation function, MGF) и по какво се отличават от "хеш функциите" (hash function), какво е key derivation function (KDF) и каква е връзката му с NIST Special Publication 800-132,  ще поговорим за това, защо е нужно да познаваме в детайли SP 800-90A, SP 800-90B и SP 800-90C, както и други стандарти, имащи непосредствено отношени към темата.

Надявам се в размките на дискусията да успеем да съхраним добрия тон и професионалната етика.

Ще се радвам ако мога да отговоря на конкретни въпроси, но държа да подчертая, че познанията ми са ограничени в много тясна и специфична сфера.

С уважение към всички, които биха проявили интерес.

Avatara

 

Не мога да кажа, че съм най-вещото лице, което познавам на тема криптография, но от това, което съм учил мога да разбера за какво говориш.

Накратко да обясня например хеш функциите преобразуват някаква входяща информация във уникална изходна репрезентация на тази информация. Използва се за удостоверяване на цялостта на данните и вместо да се съхраняват разни пароли в чист вид.

"салт" или "посоляването" е когато сторваме примерно пароли в базата данни, но искаме да ги сторнем в хеширан вид, за да ги предпазим от потенциална компрометация. Е, да ама реално дори в хеширан вид са си уязвими, защото е лесно да се отгатне чистият им вид посредством брутфорс. Обаче, ако имаме рандъм стойност, която се добавя към паролата или това, което хешираме, тогава стойността на хеша ще е напълно различна от първоначалната, заради новите добавени символи от "солта". Следователно, за да се отгатне паролата, трябва да се отгатне и случайната стойност с която е "посолена" ;д 

Сийд-а е началната стойност, която се използва при генерирането на рандъм стойности/числа. 

Интересно ми е да споделиш каква е специализацията ти в сферата на криптото, за да знам какви въпроси мога да ти задам?

[Avatara]

Здравейте,

Благодаря Ви за изключително професионално написания коментар по темата. 

Аз съм CSA (софтуерен архитект).

С криптографията ме свързва една монография и няколко патента (ORE, HCS, криптомеханизми, бюджетни постквантови решеняи и др.).

Редактирано Април 17, 2023 от Avatara

[Avatara]

ПРИЛОЖНА КРИПТОГРАФИЯ

РАЗДЕЛ I

КРИПТОПРИМИТИВИ

(със съкращения)

 

ОБФУСКАЦИЯ
(black-box obfuscation)

ДЕФИНИЦИЯ

Обфускация (от лат. obfuscare – замъгляване; англ. obfuscate – правя нещо неочевидно, объркващо) или обфускация на кода е процес на преобразуване на изходния или изпълниямия код на едно програмно приложение във вид, който при съхранение на работната функционалност, го прави труден за анализ на използваните алгоритми и на работната логика.

Целта е да се сведат до минимум негативните последствия от неоторизирана декомпилация.

Специализираните програмни приложения, които реализират процеса на обфускация се наричат обфускатори (англ. obfuscator).

Това, което е важно да се знае е, че независимо от това, че обфускацията е базов криптопримитив, към момента няма нито един случай, когато black-box obfuscation (получаване на данни само за информацията постъпваща на входа и резултатите на изхода на приложението) е доказала своята ефективност.
Това е спомагателен криптопримитив, който няма задължителен характер.

 

ОСНОВНИ ЦЕЛИ НА ОБФУСКАЦИЯТА

• Затрудняване на процесите на анализ на логиката и функционалността, в случай на декомпилация;
• Въпрепятстване на самият процес на декомпилация (например опитите за заобикаляне на DRM и лицензионната защита);
• Оптимизиране на програмата с цел намаляване на размера на изпълнимия код и (когато се използват скриптови езици) за подобряване на общата производителност на приложенията;
• Демонстрация на неочевидните възможности на езика и квалификационното ниво на разработчиците, когато не се използват специализирани програмни средства. 

 

ПРАКТИЧЕСКА РЕАЛИЗАЦИЯ

На ниво изходен код

Често се използва и като "оптимизация" (минимизация, минификация, minification) на изходния код.
Най-често се използва при скриптови езици , ползващи интерпретатори, като java Scrypt. 
Намалява количеството данни, които трябва да бъдат обработени. При web-документи позволява оптимизиране на обработката на заявките и снижаване на времето, необходимо за визуализация.

 

Пример 1

Изходен код на JavaScrypt:

var array = [];
for (var i = 0; i < 20; i++) {
  array[i] = i;
}

Модифициран код на javaScrypt:

for(var a=[i=0];i<20;a[i]=i++);

 

Пример 2

Изходен код на C/C++:

  int COUNT = 100;
  float REAL_NUMBER = 0.2;
  for (int i=0; i<COUNT; i++)
  {
    current_number[i] = original_number[i] * REAL_NUMBER;
    result_number[i] = original_number[i] + current_number[i];
  }

Модифициран код на C/C++:

for(int a=0;a<100;a++){b[a]=c[a]*0.2;d[a]=c[a]+b[a];}

 

На ниво междинен (байт) код
(bytecode, portable code)

Прилага се при .NET приложенията.

 

Забележка: Когато се прилага обфускация спрямо приложения, използващи езици за програмиране, позволяващи обръщение към обектите по името на техния клас (каквито са всички съвременни езици) преименуването е практически невъзможно. Този вид ограничение може да доведе до сериозни проблеми, ако не бъде взет под внимание. 

 

Литература:

Menezes A.J., Oorschot P.C., Vanstone S.A. Handbook of applied cryptography. — 1996. — С. 5—6. — 780 с. — ISBN 0-8493-8523-7.
Oded Goldreich. Foundations of Cryptography: Volume 1, Basic Tools. — Cambridge University Press. — 2004. — С. 223—228. — 372 с. — ISBN 0-521-79172-3.
Michela Meister. A Survey of Pseudorandom Functions // Stanford University. — С. 1. — 5 с.
Patel Parth. Cryptovirology // U & P U PatelDepartment of Computer Engineering,Gujarat University, India. — С. 6. — 8 с.

 

Редактирано Април 17, 2023 от Avatara

[Avatara]

ВАЖНИ ПОЯСНЕНИЯ

 

Преди да продължим е важно да уточним защо трябва да отчитаме спецификата на информацията, която подлежи на криптиране и защо трябва да бъдем предпазливи, когато ползваме източници по темата, напуисани на английски език.

Като начало ще се спем на някои особенности на използваната терминология и какво следва от това.

 

ШИФРИРАНЕ
(encryption)

Шифрирането е обратима трансформация на достъпна информация (която може да бъде цифрова, аналогова или от друг вид), която гарантира, че достъпът до конфеденциална (служебна, критична) информация ще бъде получен само и единствено от оторизирани за това лица.

В същото време шифроването възпрепятства възможността за несанкциониран достъп.

Процесите на шифриране и дешифриране на абстрактно ниво (математическо описание на процеса) се представят посредством математически функции, подчинении на ясно дефинирани изисквания.

Пример:

Шифриране:

    Е:М -> C 

В резултат на шифриране (encryption, E) на информацията (съобщението, message, M) получаваме шифрован резултат (crypto message, C)

    D:C -> M

Дешифриране

D:C -> C 

В резултат на дешифрирането (decryption) на шифрованото съобщение  (crypto message, C) получваме изходното съобшение (message, M). 

 

От математическа гледна точка (а и от гледна точка на приложната криптография) E, D, M и C са множества, защото може да имамем много различни съобщения (информациони масиви, данни и пр.), които могат да бъдат шифрирани/дешифрирани, при използване на различни по вид и логика шифровъчни алгоритми.

Всеки отделен елемент от тези множества m (множеството на изходните съобщения, изходните данни, source messages) c (получени резултати след шифроване, шифровани съобщения, шифровани данни, crypto messages) са аргументи (параметри) на използваната шифровъчна функция.

 

ВАЖНО!

В това описание на процеса на шифроване липсва секретния ключ (secret key) като елемент от шифровъчната функция.

 

Това е правилния запис, защото позволява абстрактен анализ на шифровъчните функции.

Секретния ключ би следвало да се разглежда като специфичен криптопримитив, което на практика го превръща в самостоятелен компонент, със своя специфика.

Ако обаче към записа добавим и секретния ключ (sekret key, К), като компонент горните уравнения добиват вида:

 

Шифриране:

    EK1(m) = c

Резултатът от шифрирането на съобщение (данни, source data, Sd) е шифрирано съобщение c (crypto message)

 

Дешифриране:

    DK2(c) - m

Резултатът от дешифрирането на шифрованото съобщение (данни, crypto data, Cd) е дешифрираното съобщение m (message).

 

Тук е важно да внеса малко пояснение, за един атавизъм, който и днес поражда редица сериозни проблеми в приложната криптография.

Когато посоченият математически апарат е разработван на шифроване са подлежали само и единствени пощенски съобщения, което е довело до така посочения начин на изписване на зависимостите.
Това може да дожеде до сериозни усложенения, породени от спецификата на шифриране на различна по вид информация.

Правилният запис (използван от всички експерти от Gate-92 DD) e следния:

    EK1(Sd) = Rd
    DK2(Rd) = Sd

където:

    E - шифровъчна функция;
    D - дешифрираща функция;
    K1 - секретен ключ, използван в процеса на шифриране (не е задължителен като елемент);
    К2 - секретен ключ, използван в процеса на дешифриране (не е задължителен като елемент);
    Sd - изходни данни;
    Rd - данни получени в резултат на проведените преобразувание.

Още по-правилния запис на така посочените уравнения обаче е:

    ECm1(Sd) = Rd
    DCm2(Rd) = Sd

 

където:

    E - шифровъчна функция;
    D - дешифрираща функция;
    Cm1 - шифровъчен (криптиращ) механизъм (crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Cm2 - шифровъчен (дешифриращ) механизъм (crypto mechanism), който е задължителен елемент от шифровъчната функция.
    Sd - изходни данни (source data);
    Rd - данни получени в резултат на проведените преобразувание (result data).

 

Забележка: Разбирането на това фундаментално различие е от изключително значение, за практическата реализация на системи (апаратни, програмни и/или друг вид) за защита на данни.

 

Независимо кой какво твърди, има сериозни различия в механизмите, по които се шифроват файлове, текстова информация, гласопренос или поточно видео.
Всяка една от така изброените информационни форми има своя специфика, която би следвало да бъде отчитана. Това обаче не се прави.

Една от най-често срещаната грешка са опитите да се създаде "универсално решение". Това води до сериозни проблеми с гарантиране на сигурността на информацията.

 

КРИПТИРАЩ МЕХАНИЗЪМ
(crypto mechanizm)

Криптиращият механизъм е набор от функции, гарантиращи съхранението на съдържанието и гарантиращи неговата цялост и степен на защита в процеса на шифриране/дешифриране на информацията.

 

Това, което е важно да се знае е, че криптомеханизмите могат да генерират секретен ключ, ако това се налага, но секретния ключ не може да генерира криптомеханизъм.

От тук непосредствено следва, че секретния ключ е елемент (компонент) от използвания криптомеханизъм, но не е задължителен елемент. Това е много по близко до абстрактното описание на шифровачния процес, което е по-правилно от гледа точка на използваните в криптографията числени методи.

Ако се отчита спецификата на процеса, горните уравнения би следвало да имат вида:

 

Шифроване/дешифриране на файлове:

    EFcm1(Sf) = Rf
    DFcm2(Rf) = Sf

където:

    Fcm1 - шифровъчен (криптиращ) механизъм за файлове (file crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Fcm2 - шифровъчен (дешифриращ) механизъм за файлове (file crypto mechanism), който е задължителен елемент от шифровъчната функция.
    Sf - изходен файл (source file);
    Rf - резултатен файл (result file).

 

Шифроване/дешифриране на информационни потоци:

    EScm1(Ss) = Rs
    DScm2(Rs) = Ss

където:

    Scm1 - шифровъчен (криптиращ) механизъм за файлове (stream crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Scm2 - шифровъчен (дешифриращ) механизъм за файлове (stream crypto mechanism), който е задължителен елемент от шифровъчната функция.
    Sf - изходен файл (Sf);
    Rf - резултатен файл (Rf).
    Ss - изходен поток (source stream);
    Rf - резултатен поток (result stream).

 

Шифроване/дешифриране на текстови съобщения:

    EТcm1(St) = Rt
    DТcm2(Rt) = St

където:

    Тcm1 - шифровъчен (криптиращ) механизъм за текст (text crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Тcm2 - шифровъчен (дешифриращ) механизъм за текст (text crypto mechanism), който е задължителен елемент от шифровъчната функция;;
    Ss - изходен текст (source text);
    Rf - резултатен текст (result text).

  
Забележка: За разлика от класическата, при тази форма на математически запис се отчита спецификата на процесите, което позвалява лесно имплементиране на високонадежни решения, използващи съвременни форми на криптиране като FFE, ORE и др.

 

КРИПТИРАНЕ
(encryption)

Криптирането е технологичен процес за обратимо преобразуване на информация, който включва набор от криптопримитиви и е подчинен на утвърдени протоколи за сигурност.

 

Обърнете внимание, че на английски език за "шифроване" и "криптиране" се използва една и съща дума "encryption".

Разликата между "шифроване" и "криптиране" е повече от фундаментална.

 

Шифорването е един от елементите, от които е изграден процеса на криптиране на информацията.

 

Разбирането на този постулат ще ни позволи да разгледаме спецификата на съвременните криптосистеми.

 

Други термини, при които често се допускат дефиниционни грешки са "оторизиран потребител" и "краен потребител" на информацията.

 

ОТОРИЗИРАН ПОТРЕБИТЕЛ
(authorized user)

Оторизирани потребители са тези, на които е гарантиран законен достъп до автентичен крипто механизъм.

 

(следва продължение)

[Кит]

преди 4 часа , Avatara каза:

ВАЖНИ ПОЯСНЕНИЯ

 

Преди да продължим е важно да уточним защо трябва да отчитаме спецификата на информацията, която подлежи на криптиране и защо трябва да бъдем предпазливи, когато ползваме източници по темата, напуисани на английски език.

Като начало ще се спем на някои особенности на използваната терминология и какво следва от това.

 

ШИФРИРАНЕ
(encryption)

Шифрирането е обратима трансформация на достъпна информация (която може да бъде цифрова, аналогова или от друг вид), която гарантира, че достъпът до конфеденциална (служебна, критична) информация ще бъде получен само и единствено от оторизирани за това лица.

В същото време шифроването възпрепятства възможността за несанкциониран достъп.

Процесите на шифриране и дешифриране на абстрактно ниво (математическо описание на процеса) се представят посредством математически функции, подчинении на ясно дефинирани изисквания.

Пример:

Шифриране:

    Е:М -> C 

В резултат на шифриране (encryption, E) на информацията (съобщението, message, M) получаваме шифрован резултат (crypto message, C)

    D:C -> M

Дешифриране

D:C -> C 

В резултат на дешифрирането (decryption) на шифрованото съобщение  (crypto message, C) получваме изходното съобшение (message, M). 

 

От математическа гледна точка (а и от гледна точка на приложната криптография) E, D, M и C са множества, защото може да имамем много различни съобщения (информациони масиви, данни и пр.), които могат да бъдат шифрирани/дешифрирани, при използване на различни по вид и логика шифровъчни алгоритми.

Всеки отделен елемент от тези множества m (множеството на изходните съобщения, изходните данни, source messages) c (получени резултати след шифроване, шифровани съобщения, шифровани данни, crypto messages) са аргументи (параметри) на използваната шифровъчна функция.

 

ВАЖНО!

В това описание на процеса на шифроване липсва секретния ключ (secret key) като елемент от шифровъчната функция.

 

Това е правилния запис, защото позволява абстрактен анализ на шифровъчните функции.

Секретния ключ би следвало да се разглежда като специфичен криптопримитив, което на практика го превръща в самостоятелен компонент, със своя специфика.

Ако обаче към записа добавим и секретния ключ (sekret key, К), като компонент горните уравнения добиват вида:

 

Шифриране:

    EK1(m) = c

Резултатът от шифрирането на съобщение (данни, source data, Sd) е шифрирано съобщение c (crypto message)

 

Дешифриране:

    DK2(c) - m

Резултатът от дешифрирането на шифрованото съобщение (данни, crypto data, Cd) е дешифрираното съобщение m (message).

 

Тук е важно да внеса малко пояснение, за един атавизъм, който и днес поражда редица сериозни проблеми в приложната криптография.

Когато посоченият математически апарат е разработван на шифроване са подлежали само и единствени пощенски съобщения, което е довело до така посочения начин на изписване на зависимостите.
Това може да дожеде до сериозни усложенения, породени от спецификата на шифриране на различна по вид информация.

Правилният запис (използван от всички експерти от Gate-92 DD) e следния:

    EK1(Sd) = Rd
    DK2(Rd) = Sd

където:

    E - шифровъчна функция;
    D - дешифрираща функция;
    K1 - секретен ключ, използван в процеса на шифриране (не е задължителен като елемент);
    К2 - секретен ключ, използван в процеса на дешифриране (не е задължителен като елемент);
    Sd - изходни данни;
    Rd - данни получени в резултат на проведените преобразувание.

Още по-правилния запис на така посочените уравнения обаче е:

    ECm1(Sd) = Rd
    DCm2(Rd) = Sd

 

където:

    E - шифровъчна функция;
    D - дешифрираща функция;
    Cm1 - шифровъчен (криптиращ) механизъм (crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Cm2 - шифровъчен (дешифриращ) механизъм (crypto mechanism), който е задължителен елемент от шифровъчната функция.
    Sd - изходни данни (source data);
    Rd - данни получени в резултат на проведените преобразувание (result data).

 

Забележка: Разбирането на това фундаментално различие е от изключително значение, за практическата реализация на системи (апаратни, програмни и/или друг вид) за защита на данни.

 

Независимо кой какво твърди, има сериозни различия в механизмите, по които се шифроват файлове, текстова информация, гласопренос или поточно видео.
Всяка една от така изброените информационни форми има своя специфика, която би следвало да бъде отчитана. Това обаче не се прави.

Една от най-често срещаната грешка са опитите да се създаде "универсално решение". Това води до сериозни проблеми с гарантиране на сигурността на информацията.

 

КРИПТИРАЩ МЕХАНИЗЪМ
(crypto mechanizm)

Криптиращият механизъм е набор от функции, гарантиращи съхранението на съдържанието и гарантиращи неговата цялост и степен на защита в процеса на шифриране/дешифриране на информацията.

 

Това, което е важно да се знае е, че криптомеханизмите могат да генерират секретен ключ, ако това се налага, но секретния ключ не може да генерира криптомеханизъм.

От тук непосредствено следва, че секретния ключ е елемент (компонент) от използвания криптомеханизъм, но не е задължителен елемент. Това е много по близко до абстрактното описание на шифровачния процес, което е по-правилно от гледа точка на използваните в криптографията числени методи.

Ако се отчита спецификата на процеса, горните уравнения би следвало да имат вида:

 

Шифроване/дешифриране на файлове:

    EFcm1(Sf) = Rf
    DFcm2(Rf) = Sf

където:

    Fcm1 - шифровъчен (криптиращ) механизъм за файлове (file crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Fcm2 - шифровъчен (дешифриращ) механизъм за файлове (file crypto mechanism), който е задължителен елемент от шифровъчната функция.
    Sf - изходен файл (source file);
    Rf - резултатен файл (result file).

 

Шифроване/дешифриране на информационни потоци:

    EScm1(Ss) = Rs
    DScm2(Rs) = Ss

където:

    Scm1 - шифровъчен (криптиращ) механизъм за файлове (stream crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Scm2 - шифровъчен (дешифриращ) механизъм за файлове (stream crypto mechanism), който е задължителен елемент от шифровъчната функция.
    Sf - изходен файл (Sf);
    Rf - резултатен файл (Rf).
    Ss - изходен поток (source stream);
    Rf - резултатен поток (result stream).

 

Шифроване/дешифриране на текстови съобщения:

    EТcm1(St) = Rt
    DТcm2(Rt) = St

където:

    Тcm1 - шифровъчен (криптиращ) механизъм за текст (text crypto mechanism), който е задължителен елемент от шифровъчната функция;
    Тcm2 - шифровъчен (дешифриращ) механизъм за текст (text crypto mechanism), който е задължителен елемент от шифровъчната функция;;
    Ss - изходен текст (source text);
    Rf - резултатен текст (result text).

  
Забележка: За разлика от класическата, при тази форма на математически запис се отчита спецификата на процесите, което позвалява лесно имплементиране на високонадежни решения, използващи съвременни форми на криптиране като FFE, ORE и др.

 

КРИПТИРАНЕ
(encryption)

Криптирането е технологичен процес за обратимо преобразуване на информация, който включва набор от криптопримитиви и е подчинен на утвърдени протоколи за сигурност.

 

Обърнете внимание, че на английски език за "шифроване" и "криптиране" се използва една и съща дума "encryption".

Разликата между "шифроване" и "криптиране" е повече от фундаментална.

 

Шифорването е един от елементите, от които е изграден процеса на криптиране на информацията.

 

Разбирането на този постулат ще ни позволи да разгледаме спецификата на съвременните криптосистеми.

 

Други термини, при които често се допускат дефиниционни грешки са "оторизиран потребител" и "краен потребител" на информацията.

 

ОТОРИЗИРАН ПОТРЕБИТЕЛ
(authorized user)

Оторизирани потребители са тези, на които е гарантиран законен достъп до автентичен крипто механизъм.

 

(следва продължение)

"Една от най-често срещаната грешка са опитите да се създаде "универсално решение". Това води до сериозни проблеми с гарантиране на сигурността на информацията."

- Опитвам се да помисля за такова универсално решение - може ли да специфицирате? ( и потенциалните проблеми, които създава) Благодаря предварително за времето ви!

[Avatara]

Здравейте,

Благодаря Ви за зададения въпрос и интереса към темата.

Ако ми позволите ще Ви дам пример, който е тема на последващи разглеждания. Става дума за цифровите сертификати, които се използват масово. Те са първото, което ми идва на ум, като опит за намиране на универсално решение на въпрос, изискващ анализ на различията. Да започнем със "съхраняването на резервно копие на използвания сертификат".

В случай на експортиране единствената защита е потребителската парола, а това вече не е достатъчно надеждно. Никога не бива да забравяме, че сертификатите съдържат под една или друга форма секретния ключ и още много "полезна" информация.

Друга сериозна уязвимост са форми, под които сертификатите се съхраняват физически върху носителя. Тук са възможни два варианта, както следва:

• Tекстови файл;
• Бинарно поле.

И в двата случая при реализация на физически достъп от страна на  лице с права на "супер администратор" (които могат да бъдат набавени при използване на bata hacking).  Да не забравяме, че както при Flame, така и при Stuxnet (който го предхождаше) бяха използвани напълно легитимни сертификати. Това вече е повече от сериозно, защото говорим за атака над промишлени контролери.

Да не споменавам, че ако сертификата се съхранява в текстови вид (като текстови файл) тогава (лично аз) бих го използвал като "контейнер" за текстова стеганография.

В този ред на мисли от години мой колега от Полша изучава действията на киберпрестъпниците, които ползват SSL, TLS сертификатите като контейнери.

Ако бъдем максимално обективни използването на цифрови сертификати (ще имаме специално разглеждане и много примери за използването им и всичко свързано с тях) не могат да се нарекат "криптиране" в пълния смисъл на тази дума. 

Защо мисля така?

Когато говорим за криптиране при използване на секретен ключ (както е при сертификатите) имаме следните процеси:

Създаване (генериране ) на секретните ключове;

Управление на секретните ключове (съхранение, използване, модифициране и пр.);

Унищожаване на секретния ключ.

Последният процес е повече от интересен, защото неминуемо ни води към сметището в Гана и институтите, построени край това сметище. Да не споменаваме за спецификата на използваните носители на информация и как се извършва "унищожаването". Файловите шредъри са само малка стъпка към един много по-сериозен процес.

Друг сериозен проблем при сертификатите е, че един секретен ключ (в рамките на експлотационния цикъл) се използва многократно за криптиране на различна по обем информация.

Нека стигнем до темата за "системна защита" и ще се върнем на тези проблеми.

А защо няма "универсален метод"?

Мога да Ви посоча куп шифровъчни системи при които няма "секретен ключ" но реално много от тях и до днес не могат да бъдат разбити (да не споменавам, че са и абсолютно непознати на професионалните криптоаналитици, но това не означава, че не се ползват). В документите на NIST, имащи отношение към този въпрос има много добри описания, които си струва да се прочетат внимателно. Освен "стандарни" съществува и цял клас "нестандартни решения", чието предназначение е да бъдат заобиколени законовите ограничения, касаещи криптопримитивите. 

Що се отнася до т.н. "универсалност" то в историята на криптографията има достатъчно много примери за несъстоятелността на подобна идея. В същото време има и примери, че при отчитане на спецификата, дори простата шифровъчна система не може да бъде разбита. Спомнете си "Феалка" и криптиращите системи на сухопътните войски на Вермахта, използвани по време на ВСВ. Съгласете се, че има голяма разлика между Хагелин-C-38 и Б-21, което никак не е случайно. 

Благодаря Ви за интересния въпрос. Ще се постарая в последващите постове ще разгледаме този проблем много детайлно при това с конкретни примери. 

P.S. Въпросът Ви ме върна към напразните опити да обясня на колегите от ДАНС, защо "времевите маркери" (използват се при ORE) не са секретни ключове, а на колегите от САЩ, защо "колодите" не са стеганография. Но определено ще отделя време и за тези въпроси, защото те имат отношение към т.н. "алтернативни методи за пост квантово криптиране".

Още ведниж Ви благодаря.

[memwarrior]

, Кит каза:

Не мога да кажа, че съм най-вещото лице, което познавам на тема криптография, но от това, което съм учил мога да разбера за какво говориш.

Накратко да обясня например хеш функциите преобразуват някаква входяща информация във уникална изходна репрезентация на тази информация. Използва се за удостоверяване на цялостта на данните и вместо да се съхраняват разни пароли в чист вид.

"салт" или "посоляването" е когато сторваме примерно пароли в базата данни, но искаме да ги сторнем в хеширан вид, за да ги предпазим от потенциална компрометация. Е, да ама реално дори в хеширан вид са си уязвими, защото е лесно да се отгатне чистият им вид посредством брутфорс. Обаче, ако имаме рандъм стойност, която се добавя към паролата или това, което хешираме, тогава стойността на хеша ще е напълно различна от първоначалната, заради новите добавени символи от "солта". Следователно, за да се отгатне паролата, трябва да се отгатне и случайната стойност с която е "посолена" ;д 

Сийд-а е началната стойност, която се използва при генерирането на рандъм стойности/числа. 

Интересно ми е да споделиш каква е специализацията ти в сферата на криптото, за да знам какви въпроси мога да ти задам?

Малко offtopic за Здрасти на Avatara. 😉

Хеш функциите не са препоръчителна употреба сами. Всяка една от тях има има INIT стойности които са направо като "ела вълчо изяж ме" - в един дъмп с просто бинарно търсене и лъсва първата следа ... Соленето и MAC-a си има други кусури.... Например при HMAC-a маскирането на iPAD и OPAD масивите (което е един прост XOR с 0x36 и 0x5C много лесно се намират в паметта. А ipad масива си е находка - КЛЮЧА на HMAC-a. Просто трябва малко по-завързана историика да се приложи.

 

[Avatara]

Здравей,

Признавам, че много се радвам да те видя отново. Не сме се срещали (виртуално) от години и е хубаво, че отново сме заедно.

Напълно съм съгласен с всичко, което си написал за хеш функциите.  Повярвай, ще отделим много голямо внимание на тази тема.

Ако бъда максимално откровен дори шифровъчните алгоритми (независимо колко надеждни са) не бива да се използват самостоятелно.

Наистина много се радвам. Повярвай, но дискусиите ми липсваха. 

Бъди здраве и се надявам този път да можем да дискутираме дълго.

До скоро.

P.S. Псевдонимът ми е силно познат от предходния форум, който бе закрит. Надявам се да не съм сбъркал и да си този, за когото те мисля. Дано скоро и други от "старците" се присъединят. И дано този път най-после успеем да се съберем и да изпием по бира.

Редактирано Април 19, 2023 от Avatara

[h3xu]

преди 39 минути, Avatara каза:

Здравей,

Признавам, че много се радвам да те видя отново. Не сме се срещали (виртуално) от години и е хубаво, че отново сме заедно.

Напълно съм съгласен с всичко, което си написал за хеш функциите.  Повярвай, ще отделим много голямо внимание на тази тема.

Ако бъда максимално откровен дори шифровъчните алгоритми (независимо колко надеждни са) не бива да се използват самостоятелно.

Наистина много се радвам. Повярвай, но дискусиите ми липсваха. 

Бъди здраве и се надявам този път да можем да дискутираме дълго.

До скоро.

P.S. Псевдонимът ми е силно познат от предходния форум, който бе закрит. Надявам се да не съм сбъркал и да си този, за когото те мисля. Дано скоро и други от "старците" се присъединят. И дано този път най-после успеем да се съберем и да изпием по бира.

Извинявам се за офтопик-а, но с удоволствие бих организирал подобно събитие, на което да си кажем "здрасти".

[memwarrior]

преди 12 часа , Avatara каза:

Здравей,

Признавам, че много се радвам да те видя отново. Не сме се срещали (виртуално) от години и е хубаво, че отново сме заедно.

Напълно съм съгласен с всичко, което си написал за хеш функциите.  Повярвай, ще отделим много голямо внимание на тази тема.

Ако бъда максимално откровен дори шифровъчните алгоритми (независимо колко надеждни са) не бива да се използват самостоятелно.

Наистина много се радвам. Повярвай, но дискусиите ми липсваха. 

Бъди здраве и се надявам този път да можем да дискутираме дълго.

До скоро.

P.S. Псевдонимът ми е силно познат от предходния форум, който бе закрит. Надявам се да не съм сбъркал и да си този, за когото те мисля. Дано скоро и други от "старците" се присъединят. И дано този път най-после успеем да се съберем и да изпием по бира.

😉 Правилно мислиш Avatar-е ... Аз съм от предишния форум.... А за бирата съгласен с две ръце....

 

[Avatara]

НЯКОЛКО ВАЖНИ ПОЯСНЕНИЯ

Преди да продължим с разглеждането на въпросите, касаещи приложната криптография, ще си позволя мал;ко, но изключително вважно отклонение.

Причината за това е официално писмо на колегите оът NIST, визиращо проблеми, които стават все по актуални, но не намиращи своето решение от десетилетия.

Като начало нека да видим защо е важно да се изучават стандартите?

Изучаването на стандартите е в основата на криптографската наука.

Ако пренебрегвате стандартите (ISO, NIST, ГОСТ и др.) е по-добре никога да не се заемате с приложна криптография.

Ако не вярвате на думите ми си задайте въпроса какво знаете за хомоморфните сигнатури и защо те са от критично значение за функционирането на internet?

В своите публикации многократно съм обръщал сериозно внимание на въпросите, свързани с анализа на комуникационните пакети. За съжаление освен мен и един колега от Полша (който работи за специализирано военно звено), никой друг не желае да признае съществуването на проблема.

Нека обясним проблемът на достъпен език.

Това, че сте създали някакъв "защитен" канал за обмен на данни (например VPN), не означава, че информацията, която обменяте по него е защитена.

За да бъда обектитвен трябва да отбележа е, че Денис Чарлз (Denis Charles), Кристин Лаутер (Kristin Lauter) и Камал Джейн (Kamal Jain) са предложили много интересно решение на този проблем. Решението е известно като "homomorphic encryption"

Хомоморфизмът (homomorphic, от гръцката дума ὁμός - равен , идентичен с, еднакъв  и μορφή - вид, форма) — е много често използван морфизъм в алгебраичните системи. На практика това е "отражение" на нещо в нещо друго (отражение на параметрите, функционалността и ако щете отделните стойности на едно множество или система в друга подобна система). 

Отражението не е самият обект, но ни позволява да получим информация за него.

 

Пример:

Отражението в огледалото ви позволява да видите лицето си.

Да, но отражението на вашето лице в огледалото не е самото лице.

Ако ударите отражението е вероятно да счупите огледалото, но лицето ви ще остане незасегнато. 

 

Силно се надявам горния пример, да ви е позволил да добиете някаква представа (макар и твърде повърхностна) за това какво е хомоморфизмът (да не се бърка със сексуална ориентация, защото е нещо много различно). 

В съвременната приложна криптография хомоморфизмът се среща много по-често отколкото предполагате и на практика всеки един от вас се е сблъсквал с него. Но голямото предимство, което той предоставя е възможността за анализ (оценка) на криптирани данни без да имаме информация за използвания секретен ключ (както вече споменах в предходните си постове, такъв може и да няма). И сега внимавайте много.

 

Хомоморфното криптиране не е нищо повече от до болка познатото ни асиметрично криптиране, при което се използват два ключа (публичен и секретен), но в друга форма.

 

До тук добре, но предполагам, че някой, който чете внимателно ще ми зададе въпроса:

А какво общо има това със стандартите и тяхното познаване?

Отговорът е, че ако познавате стандартите и ги четете внимателно, цялата информация, която ще мнамерите в internet по темата и която ще ви обърка повече от допустимото, става елементарна и разбираема.

И тук отново ще си позлужа с пример.

 

Пример:

 

В края на септември 2021 г. уебсайтът на ISO обяви публикуването на ново, трето издание на ISO/IEC 18033-1:2021 „Информационни технологии – Алгоритми за криптиране – Част 1. Информационна сигурност – Алгоритми за криптиране – Част 1: Общи положения.

Документът е изготвен от техническия подкомитет SC27 „Информационна сигурност, киберсигурност и защита на поверителността“ на Съвместния технически комитет на Международната организация по стандартизация (ISO) и Международната електротехническа комисия (IEC) JTC1, като замени предишната версия на ISO /IEC 18033-1:2015.

В уводната част на документа се отбелязва следното:

„Серията от стандарти ISO/IEC 18033 определя изискванията към системите за криптиране, за да се гарантира поверителността на данните."

Малко по нататък може да прочетете следния пасаж:

"Основната цел на системите за криптиране е да защитават поверителността на съхраняваните или предаваните данни. Алгоритъмът за криптиране се прилага към оригиналните некриптирани данни (обикновен текст) и произвежда криптирани данни (шифрован текст).

Този процес е известен като "криптиране".

Алгоритъмът за криптиране трябва да бъде проектиран така, че от криптираните данни да не може да се получи никаква информация за оригиналните данни, с изключение евентуално на техния обем (дължината на некриптирания текст). С всеки алгоритъм за криптиране е свързан съответен алгоритъм за декриптиране (дешифриране), който преобразува криптираните данни обратно в оригиналните некриптирани данни.

Системите за криптиране работят с ключ.

В системите за симетрично криптиране един и същ ключ се използва както в алгоритмите за криптиране, така и в алгоритмите за декриптиране. Системите за асиметрично криптиране използват различни, но взаимосвързани ключове за криптиране и декриптиране.

ISO/IEC 18033-2 и ISO/IEC 18033-5 разглеждат два различни класа системи за асиметрично криптиране, известни като „традиционна система за асиметрично криптиране“ (или просто „система за асиметрично криптиране“) и „система за криптиране, базирана на идентичност“."

Сега се замислете много добре, кое е толкова важно в така цитирания пасаж?

Обърнахте ли внимание на последното изречение. Там изрично е написано, цитирам: „система за криптиране, базирана на идентичност“.

Тук е важно да се абстрахирате от човешката представа за "идентичност" и да разсъждавате от гледна точка на крипто науката. Дори да разгледаме само този кратък пасаж няма как да не видим, колко много (и най-вече изключително полезна информация) съдържа той.

Ако изчетете стандарта до самия край, ще научите още мнго неща, касаещи хомоморфното криптиране и не само него. При това всичко е обяснено повече от достъпно.

Ако обаче искате да се занимавате с проблема професионално ще се наложи да се запознаете с много по-сериозни публикации.

Ето само две от тях:

 

Short Signatures from the Weil Pairing

On-the-Fly Verification of Rateless Erasure Codes for Efficient Content Distribution

 

И тук ако ми позволите искам да обърна внимание на един важен въпрос, който често се пренебрегва:

Обърнете внимание на втората публикация. Вижте как са описани алгоритмите. Това, че някой си позволява да описва алгоритми на някакъв конкретен скриптов програмен език (например Python, Java и др.) е грешка, която би следвало внимателно да избягвате, когато става дума за криптиране и описание на крипто алгоритми. 

Това е изключително сериозен казус, на който ще отделим специално внимание и ще разясним защо това е толкова важо, най-вече когато става дума за сертификация и/или патентоване (повечето алгоритми са патентовани, а най-добрите никога няма да намерите в "открит код"), както и за процесите имащи отношение към стандартизацията.

И за да разберете до колко е важно това, ще посоча само един факт.

Трябва да се отбележи, че въпреки че стандартите от серията ISO/IEC 18033, както и техните аналози от NIST не са адаптирани в Русия, те са посочени в редица руски стандарти и регулаторни документи. Това важи и за държавите от Далечния Изток в т.ч. и Китай.

Мисля, че сами разбирате до колко това е важно и защо трябва да бъдем много внимателни, когато се доверяваме на твърдения, разпространявани в някои информационни ресурси. Истината е, че неспазването на действащите стандарти възпрепятства умишлено технологичното развитие.

Стандартите не са ограничение, а са солидна база върху която се гради.

Редактирано Май 2, 2023 от Avatara

[Avatara]

ХИБРИДНИТЕ ФОРМИ НА КРИПТИРАНЕ КАТО АЛТЕРНАТИВА НА ЦИФРОВИТЕ СЕРТИФИКАТИ

(сравнение между стандартните хибридни методи и шифроване с цифров сертификат) 

 

Описание на основните проблеми

Всеки един специалист по информационна сигурност познава в детайли цифровите сертиификати и методите на тяхното използване. Това обаче не може да се каже за хибридните форми на стандартно криптиране, които се използват за защита на критична информация.

Цифровите сертификати се прилагат масово, като най-широко приложение те намират прио защитата на сървърни и корпоративни решения. 

Хибридната защита се използва от големите корпорации, както и от аналитични ведомства, обработващи критични данни.

При използването на цифрови сертификати, съществува слабо изучена уязвимост (най-вече в случаите на използване на специализирани апаратни и програмни средства, за неоторизиран достъп). 

Целта на настоящите разглеждания е анализ тези уязвимости, и посредством конкретни примери да потърсим алтернатиовно бюджетно решение за преодоляване на съществуващия проблем. 

Като начало ще започнем с една от тезите, която не се подлага на съмнение.

 

ТЕЗА

Криптираните, при използване на цифров сертификат файлове са недостъпни за несанкциониран достъп от неоторизирано лице.

 

Това твърдение е частично вярно.

За съжаление съществуват редица специфични решения (в т.ч. и граждански такива), които позволяват получаване на несанкциониран достъп до цифрово съдържание, криптирано с помощта на цифров сертификат. 

 

Фиг.1. Визуализация на съдържанието на файл, криптиран посредством цифров сертификат.

 

Ако внимателно разгледате Фиг.1 няма как да не забележите нещо нередно. В дясната част на приложението ясно се вижда съдържанието на криптирания файл. От гледна точка на защитата на цифровите данни това е абсолютно недопустимо.

Очевидно е, че файлът PI_004.png не би следввало да бъде достъпен, защото е криптиран, но това не се случва.

 

ВАЖНО!

В конкретния случай е без значение вида на използваната операционна система. Тук проблемът е в това какво и как се криптира.

 

Освен, че съдържанието на файла става достъпно за неоторизиран потребител (потребителят не само няма права на супер администратор, но реално той няма никакви права да използва тази компютърна конфигурация),  може да получим още куп информация за файла, която би позволила безпрепятствено манипулиране на съдържанието по начин, който би гарантирал, че това няма да бъде забелязано от File integrity monitoring (FIM) системите.

 

РЕШЕНИЕ НА КАЗУСА

За да бъдат избегнати подобни проблеми (без значение дали става дума за локални и/или сървърни файлове) е необходимо да се извърши хибридно криптиране, при използване на набор от стандартизирани и доказали се криптопримитиви.

За разлика от използването на цифрови сертификати, в този случай потребителската парола няма определящо значение за гарантиране на степента на защита.

На практика паролата, като елемент от множеството криптопримитиви е напълно излишна, но е добре да бъде оставена, за да може потребителите, както и тези, които се стремят към неоторизиран достъп, да вярват, че файловете са защитени с парола и да се стремят да я получат.

Това е типичен пример за практическа реализация на основното правило, а именно: "оставете ги да вярват".

 

Фиг.2. Използване на стандартна форма на криптиране без да бъде въведена потребителска парола. 

 

За да илюстрираме ефекта от реално криптиране на файловете, ще извършим такова, при използване на ограничен набор от криптопримитиви и липса на каквато и да било потребителска парола.

 

Фиг.3. Резултат от стандартна криптопроцедура 

 

Както може да се види от Фиг.3. в резултат на криптирането съдържанието на файла става абсолютно недостъпно, дори в случаите, когато се използват специализирани апаратни и програмни решения. На практика това е защита оът Ниво 2 po NIST, която би могла да се прилага дори в случаите на документи, класифицирани с гриф "Строго секретно". 

За нуждите на бизнеса обаче това е гаранция, че всички документи, класифицирани като "документи за служебно ползване" ще бъдат надеждно защитени.

 

Фиг.4. Резултат от стандартна криптопроцедура 

 

При декриптиране на криптирания файл, също няма да използваме парола. 

В този случай естествено възниква въпроса:

А каква е гаранцията, че ако използваме абсолютно същото приложение и не използваме потребителска парола няма да декриптираме файла?

За разлика от цифровите сертификати в този случай имаме специфика, която е добре да се отчита.

Като начало е нужно да си припомним, че криптирането се извършва с набор от криптопримитиви, за който (както сами може да видите) ние не знаем абсолютно нищо. 

В конкретния случай за шифроването на изображението са ползвани криптиращ алгоритъм, хеш функция, KDF и MGF функции, последователност от филтриращи байтове и пр. и пр. и пр.

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

Теоретично може да се извърши несанкционирано декриптиране, но за целта ще са нужни няколко десетки квантови компютъра, които да работят без прекъсване около 50 000 години, като дори тогава резултатът не е гарантиран.

 

 

Фиг.5. Резултат от декриптиране на файла

 

След като файлът бъде декриптиран той може да бъде използван по предназначение.

Тук също има специфика.

Файлът може да бъде направен достъпен само и единствено за конкретна работна станция.

В този случай дори да копирате файла, дори да разполагате с пълна информация за изполваните криптопримитиви и последователността на операциите няма да бъдете в състояние да декриптирате файла на неоторизирана машина.

Възможно е това ограничение да бъде блокирано, но може да се наложи ограничение за използването на файла само и единствено в рамките на конкретна компютърна мрежа.

На практика това означава, че дори информацията да бъде презаписана на външен носител тя ще бъде неизползваема, освен определената за това зона. В този случай се прилагат вградените DLP механизми.

 

Фиг.6. Списък на два от използваните в примера криптомеханизми.

 

Както може да се види от Фиг.6. в случая използвахме стандартни криптомеханизми. Това, което е добре да се знае е, че независикмо кой какво твърди (най-вече кое се счита за "остаряло") в практическата криптография се работи само и единствено с примитиви, които са преминали през проверка (оторизация) от упълномощениете за това инстиитуции.

За разлика от използването на цифровите сертификати, при които имаме фикциран брой шифровъчни алгоритми и хеш функции, при хибридните решения не е така.

Друга сериозна разлика е в начина, по който се използват хеш функциите.

В този случай хеш функцията не се използва за "подписване" защото на практика това се обезмисля от самия характер на използвания протокол за защита. 

Ако при стандартните форми на "подписване" се използва една хеш функция, тук се използва набор от функции (в т.ч. и хеш, но не само), които определят крайния резултат.

Така направените разглеждания важат в пълна сила и при използването на виртуални дискове, виртуални работни места, облачни решения и пр..

 

ВАЖНО!

Всяко виртуално решение е обвързано с конкретен физически запис, върху физически носител.

 

Разбирането на гореизложеното е от изключително значение. Сама по себе си стандартната защита на виртуалните решения не гарантира достатъчно високо ниво на сигурност.

 

Фиг.7. Създаване на защитен виртуален диск.

 

Въпросите за защита на виртуални решения и облачни технологии, са тема на отделни разглеждания, но обективно погледнато при хибридните методи на защита е без значение не само вида на използваната операционна система, но и къде физически са разположени данните (на локално или сървърно или  виртуално устройсто, в облака, на мобилно устройсто, на външен носител и пр.). При хибридните технологии се криптира самото съдържание на ниво байт. Разбирането на тази специфика е от изключително значение.

Редактирано Май 9, 2023 от Avatara

[Avatara]

А сега малко теория за да разберем какво точно представляват криптографските примитиви.

 

КРИПТОГРАФСКИ ПРИМИТИВИ

 

ДЕФИНИЦИЯ

Криптографските примитиви са основните градивни елементи на протоколите и системите, използвани за защита на цифрови данни.

 

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

В практиката се използват различни видове протоколи за сигурност. Като най-масово използваните може да посочим удостоверителните протоколи,  протоколите за гарантиране целостта на данните, протоколите за управление на секретните ключове и др..

 

ВАЖНО!

Криптографските примитиви са проектирани да изпълняват една специфична задача по точно определен начин, при гарантиране на висока експлотационна надеждност. 

 

СПЕЦИФИКА НА КРИПТОГРАФСКИТЕ ПРИМИТИВИ

Тъй като криптографските примитиви се използват като градивни елементи на всяка една криптосистема, те би следвало да бъдат изключително надеждни, т.е. да работят според техническата спецификация и съпътстващите ги предписания.

 

Например, ако в документацията се посочва, че криптографски примитив може да бъде разбит с N брой операции, но е възможно да бъде разбит с N-1 операции, тогава този криптографски примитив се счита за дискредитиран.

 

Ако се установи, че един криптографски примитив е дискредитиран, почти всеки протокол, който го използва, се счита за недостатъчно надежден, за да осигури сигурна защита на критична информация.

 

Тъй като създаването на криптографски процедури е много трудно и тестването им за надеждност отнема много време, по същество никога не е разумно (нито сигурно) да се проектира нов криптографски примитив, който да отговаря на нуждите на нова криптографска система.

Като основни причини за това ограничение може да посочим:

• Познанията на разработчика, свързани с математическите и техническите теоретични модели, използвани в криптографията, не са на необходимото ниво.
• Проектирането на нов криптографски примитив отнема много време и е много податливо на грешки, дори за експерти в тази област.
• Криптоалгоритмите, които са теоретичната основа, върху която са проектирани отделните примитиви, трябва да бъдат анализирани в детайли. Въпреки че може да изглеждат изключително надеждни, е възможно да възникне грешка в резултат на неправилно проектиране.

 

Независимо от всички теоретични и експериментални проверки, към момента няма методика, гарантираща сигурността на защитните механизми. Единственото решение, доказало своята ефективност, е правилната комбинация от използваните крипто примитиви.

 

Забележка: Криптографските примитиви са подобни в някои отношения на езиците за програмиране. Компютърният програмист рядко измисля нов език за програмиране, докато пише нова програма, вместо това се използва един от вече установените езици за програмиране.

КОМБИНИРАНЕ НА КРИПТОГРАФСКИ ПРИМИТИВИ

Криптографските примитиви сами по себе си са доста ограничени. Те не бива да бъдат представяни като криптографска система.

 

Например алгоритъмът за шифроване на цифрови данни не може да осигури механизъм за удостоверяване или задължителна проверка на целостта на данните.

 

ВАЖНО!

Само и единствено когато се извършва комбиниране на различни протоколи за сигурност, може да се отговори на повече от едно изискване за сигурност.

 

Например, за да се предаде съобщение, което е не само шифровано, но и защитено от редактиране (т.е. неговатя цялост е защитена), може да се използват в комбинация примитив за кодиране, като DES, и хеш функция, като SHA-1 (примерно).

В този случай ако неупълномощеният потребител не е в състояние да получи достъп до секретния ключ, той не би могъл да модифицира цифровите данни. 

Комбинирането на криптографски примитиви за създаване на протокол за сигурност само по себе си е специфично научно направление.

 

Повечето грешки при разработката и/или използването на криптосистеми се дължат не на грешки в дизайна на примитивите (ако приемем, че те са подбрани внимателно и съответства на действащите стандарти), а на начина, по който се използват, т.е. лош дизайн на протокола и бъгове или недостатъчно внимателно изпълнение на крайните решения.

Някои от основни свойства на криптопримитивите могат да бъдат проверени с автоматизирани методи, като BAN логика. Има дори методи за пълна проверка (напр. SPI изчислението), но те са изключително тромави и не могат да бъдат автоматизирани.

 

Забележка: Проектирането на протоколи е специфична сфера в кибернетичната сигурност, изискващо задълбочени познания и много практика, но дори тогава грешките са често срещани.

 

ЧЕСТО ИЗПОЛЗВАНИ КРИПТОГРАФСКИ ПРИМИТИВИ

Между теоретичната и практическата криптография съществуват сериозни различия, които се изразяват най-вече в избора на основни крипто примитиви, които формират механизмите за сигурност.

Най-често в практиката се използват следните процедури:

• Универсална еднопосочна хеш функция (universal one-way hash function, UOWHF) - Понякога се нарича още функция за еднопосочна компресия.  Математически алгоритъм, който преобразува данни с произволен размер (често наричани „съобщение“) в масив от битове с фиксиран размер (наричан  „хеш стойност“, „хеш“ или „хеширано съобщение“). Функцията има необратим характер. От това следва, че практически е невъзможно да се извърши обратно преобразуване. В идеалния случай единственият начин да се намерите съобщението, за което е генериран даден хеш, е да се изпробрват всички възможни комбинации, до откриване на съвпадение. Освен това съществуват и други методи за анализ, целящи съкращаване на необходимия брой операции. Основно изискване към хеш функциите е гарантурана устойчивост към колиции (не бива да имаме две еднакви хеш функции за различни "съобщения");
• Криптография със симетричен ключ (symmetric-key algorithm) - Метод за криптиране, който използва един и същи секретен (криптографски) ключ както за криптиране (шифроване), така и за декриптиране (дешифриране). Преди изобретяването на схемата за асиметрично криптиране единственият съществуващ метод беше симетричното криптиране. Ключът на алгоритъма трябва да се пази в тайна и от двете страни, трябва да се вземат мерки за защита на достъпа до канала, както и от взаимодействащите си страни. За целта се използват крипто обекти. В съвременните хибридни решения, гарантиращи най-високата възможна степен на защита освен обекти (object relation encryption, ORE) се използват и криптомеханизми;
• Криптография с публичен ключ (асиметрично криптиране) - Криптографията с публичен ключ (например RCA), известна още като асиметрична криптография, е метод, при който се използва както секретен (частен, private key), така и публичен ключ (отктит, public key), за разлика от секретния ключ, използван в симетричното криптиране. Използването на двойки ключове дава уникален набор от характеристики и възможности, които могат да се използват за решаване на проблеми, присъщи на други криптографски методи. Този метод е в основата на HyperText Transfer Protocol Secure, HTTPS;
• Алгоритъм за цифрово подписване (Digital Signature Algorithm, DSA) - Криптографски алгоритъм, базиран на секретния ключ, при системите с асиметрично криптиране (секретен ключ/публичен ключ), за генериране на електронен подпис, удостверяващ подателя. Не се използва за криптиране на данни, а само и единствено като един от възможните методи за удостверяване. За справка вижте DIGITAL SIGNATURE STANDARD (DSS), U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, както и последващите стандарти ;
• Смесена мрежа () - Набор от протоколи за маршрутизиране, които създават труднопроследима връзка, използвайки верига от прокси сървъри, известни като миксове, които приемат съобщения от множество потребители, смесват ги и ги препращат произволно към следващата дестинация (вероятно друг микс възел). Това прекъсва връзката между източника на съобщението и получателя, което прави по-трудно прихващането на съобщението при комуникация от край до край. Освен това всеки възел знае само информация за предишния възел и адреса на следващия получател. Независимо, че смесените мрежи осигуряват сигурност, дори ако нападателят вижда целият маршрут, смесването не е абсолютно надежният начин да останете анонимни. Нападателите могат да провеждат продължителни корелационни атаки и да проследяват подателя и получателя на пакетите (за справка Sleeping dogs lie on a bed of onions but wake when mixed) ;
• Получаване на скрита информация (private information retrieval,  PIR) -  В криптографията протоколът за извличане на информация (PIR) позволява на неооторизиран потребителя да извлича лична информация, представляваща интерес, от един и/или няколко различни сървъра. Освен това сървърът няма да може да разпознае коя част от неговата информация е станала известна на неоторизирания потребител. Това е основен компонент при защитата на СУБД, който е изключително пренебрегван. Повече информация за едно от възможните приложения, може да намерите в статията Private Information Retrieva;
• Побитова схема на обвързване (Commitment scheme) - Криптографски примитив, който ви позволява да фиксирате всяка избрана стойност (избран бит информация), като я запазите скрита, с възможност за по-късно разкриване (виж Zero-Knowledge Proofs for NP: Commitment Schemes, Foundations of Cryptography Basic Tools, Volume 1). Обвързващите схеми са проектирани по такъв начин, че да не може едностранно да се промени стойността или съдържанието, след като са били изпратени, т.е. схемите на обвързване предполагат обвързване на данните. Схемите за обвързване намират приложение в редица криптографски протоколи, включително нулево доказателство, поверителен изчислителен протокол и други. Още през 1997 година този криптопримитив добива изключителна актуалност във връзка с въпросъте, касаещи разпределението на секретни ключове, при постквантовите криптиращи системи (за справка Unconditionally secure quantum bit commitment is impossible, проблем, който се разрешава с използване на хибридни методи);
• Генератори на случайни числа (random number generator) - Генерирането на случайни числа е процес, при който се  избира произволно число в зададен диапазон с помощта на алгоритми. Една от най-често срещаните грешки е да се сравняват генераторите на случайни числа с генераторите на псевдослучайни числа. Разликата е, че при генераторите на случайни числа се извършва случаен избор в зададен интервал.

 

Фиг.1. Взаимодействие между някои от най-масово използваните криптопримитиви.

 

 

Това са малка част от най-масово използваните криптопримитиви, но списъкът е много по-дълъг.

Темата е безктрайно интересна, а и обективно погледнато това е основата на обектно-релационното криптирабе, контролните низове и много други съвременни технологии, които са непознати на широката публика (а ако бъда честен дори на експертите).

Редактирано Май 10, 2023 от Avatara

[Avatara]

КРИПТИРАНЕ В РЕЖИМ НА ПАКЕТНА ОБРАБОТКА

(Package Mode Encryption, PME)

 

Преди да продължим с разглежданетоо на темата, нека ви запозная с последните продукти от продуктовата група CRYPTHOR™ Project.

 

Новостите са много, защото вече е достъпна версия 2.7.0.0.

Да започнем с най-голямата промяна. Тя е в използването на т.н. "контролни стрингове" (control strings).

Тези, които вече са ползвали тази функционалност знаят, че контролните стрингове позволяваха генериране, съхраняване и пренос на криптопримитиви (шифровъчни алгоритми, режими на шифроване, методи на кодиране, хеш функции, инициализиращи вектори, филтриращи байтове и пр. и пр.) в неявен вид.

Това е един изключително мощен инструмент за изграждане на високоеефективни бюджетни постквантови решения.

 

При версия 2.7.0.0 са запазени интерфейсни прилики с предходните версии на модула, но разликите във функционалността е повече от гопляма.

 

Фиг.1. Новият дизайн на модула за формиране на контролни стрингове.

 

Една от най-интересните новости е възможността, от използване на колоди (набор от цифрови изображения), която бе недостъпна за потребителите в предишните версии.

Освен при контролните стрингове, значителни изменения има и при системите за обектно-релационно криптиране. Тук хибридната стеганография се използва не само и единствено, като средство за пренос на данни, а вече е пълноценен инструмент за симетрично формиране на секретни ключове, което на практика се явява алтернатива на асиметричното криптиране, но без да наследява неговите недостатъци.

 

Фиг.2. Използване на публичен ресурс за генерация на симетрични секретни ключове.

 

За тези, които обаче се придържат към използването на удостверителни сертификати също е помислено. Във всички приложения са включени модули, позволяващи оптимизиране на работата с цифрови сертификати.

 

Фиг.3. Стандартен модул за работа с удостверителни сертификати.

 

Не е забравена и нестандартната стеганография, позната ни от BS-1433. Новото тук е възможностт за тотално премаване на необходимостта от наличие на "празен контейнер", което елиминира една от най-сериозните заплахи, при използване на стеганографски методи за пренос на данни.

 

Фиг.4. Хибридна стеганография

 

Помислено е и за web-базираните решения. От мощни REST крипто-сървъри, до богат набор от инструменти за тестване и управление жизнения цикъл на работни скриптове.

Но най-интересни са т.н. Local Broadcasting системи, позволяващи изгражданена цифрови телевизионни и радио канали, излъване на филми и много други неща. Ако имате в дома си смарт телевизор, това може да се окаже сериозна конкуренция на NETFLIX и други подобни ресурси.

 

 

 

[Avatara]

ВАЖНО!

За всички регистрирани потребители на hacking.bg платените версии на приложенията, от продуктовата група CRYPTHOR™ се предоставят напълно безплатно, след като потребителя направи заявка на сайта.

След като завката бъде одобрена, потребителя ще получи промоционален код, който ще му позволи да ползва приложенията след изтичане на тестовия период.

 

Официалните адреси в MS Store, от които може да получите приложенията са както следва:

 

• FDM II spe - Професионален шредър с възможност за пакетна обработка на избраните файлове.
• FPM II spe - Полупрофесионално решение за пакетна защита на големи масиви от файлове.
• File Protect System SE - Професионално решение за защита на файлове и директории.

 

Ще бъда лично признателен за всяка една забележка и препоръка, която направите. В случай на заинтересованост аз и колегите имаме готовност за предоставяне на допълнителна информация.

Забележка: В момента помощната информация се актуализира. Причината за това е изключително високата динамика на актуализации от последните шест месеца.

 

 

Редактирано ноември 9, 2023 от Avatara

[Avatara]

КАКВО НЕ ЗНАЕМ ЗА ЕЛЕКТРОНИЯ ПОДПИС?

На 3 февруари 2023 г. Националният институт за стандарти и технологии (NIST) пусна новото издание на своя Федерален стандарт за обработка на информация (FIPS) NIST FIPS 186-5 Стандарт за цифров подпис (DSS)) от 86 страници, вижте Digital Signature Standard (DSS), заменящ предишния FIPS 186-4, публикуван през юли 2013 г.

Както е отбелязано в резюмето: 

"Този стандарт определя набор от алгоритми, които могат да се използват за създаване на цифров подпис. 

Електронните цифрови подписи се използват за откриване на неоторизирани модификации на данни и за удостоверяване на самоличността на подписващия. 

В допълнение, получателят на подписаните данни може да използва цифровия подпис като доказателство, за да докаже на трета страна, че подписът наистина е създаден от заявения подписал. 

Това свойство е известно като "неотказ", тъй като подписващият не може лесно да оттегли подписа по-късно.“

 

Съдържанието на документа е следното:

Предговор

1. Въведение
2. Речник на термините, съкращенията и математическите символи
3. Общи положения
4. Алгоритъм за електронен цифров подпис (DSA)
5. Алгоритъм за цифров подпис RSA
6. Алгоритъм за електронен цифров подпис върху елиптични криви (ECDSA)
7. Алгоритъм за електронен цифров подпис, базиран на кривата на Едуардс (EDDSA)

Приложение A: Генериране на двойка ключове
Приложение B: Генериране на други величини
Приложение C: Изчисляване на необходимия брой  рекурсивни цикли на тестване с помощта на вероятностния тест на Милър-Рабин

Промените в стандарта са от месец февруари тази година.

Въпропсът е: А има ли република България действащ стандарт, съобразен с настъпилите пронмени в тази сфера?

А ЕС? До колко ISO е приведен в съответствие с новите реалности?

Проблемът е, че когато говорим за удостверителни сертификати винаги и приоритетно се дискутира правната и финансовата страна, но техническата остава на заден план.

Това обаче може да породи редица проблеми, които биха могли да имат катастрофални последици.

Какво ни дава основание за подобно твърдение?

Нека разгледаме технологията на електронно подписване и да се опитаме да отговорим на следния въпрос:

 

КАКВО ТОЧНО ГАРАНТИРА ЕЛЕКТРОННИЯ ПОДПИС?

Това, което трябва обаче да отчетем, че отговорът на този изключително важен въпрос се съдържа в NIST FIPS 186-5 във ясно дефинираното предназначение на цифриовите сертификати, а именно:

 

"Електронните цифрови подписи се използват за откриване на неоторизирани модификации на данни и за удостоверяване на самоличността на подписващия."

 

Очевидно е, че говорим само и единствено за удостверяване на самоличност (оторизация, валидизация на потребителите), но не и за комплексна защита.

Но нека отидем малко по-далеч и зададем следващият по важност въпрос:

 

"А КАКВО ТОЧНО ЗАЩИТАВАТ СЕКРЕТНИТЕ КЛЮЧОВЕ, СЪДЪРЖАЩИ СЕ В ЦИФРОВИЯ СЕРТИФИКАТ И ДАЛИ ТОВА НЕ Е ПРЕДПОСТАВКА ЗА УЯЗВИМОСТ?"

 

За да получим отговор, ще се наложи да разгледаме технологичния проце на подпиисване от момента на създаване (генериране на сертификата, до неговото използване, както за посписване на електронни документи, така и за управление на транзакции, за защита не web-ресурси и др..

Цифровите сертификати използват изключитъелно ограничен набор от стандартни криптографски примитиви.

В редица източници, ще срещнете твърдението, че те, цитирам: 

"Включват използването на стандартни криптографски алгоритми".

Това твърдение е много по-близо до истината, защото не всички криптографски примитиви са алгоритми.
Например т.н. "филтриращ байт", който е стандартен елемент в приложната криптография и се ползва масово, но няма нишо общо с какъвто и да било алгоритъм.
Това важи и за редица други примитиви, като т.н. "сиви ключове", контролни стрингове, делта параметри и пр. и пр.

Ако бъдем максимално обективни удостверителните сертификати имат много малко общо със съвременните криптографски системи.

Де факто EDS обикновено се основава на асиметрично криптиране (Ралф Меркъл), чиято идея е изключително проста: два различни ключа се използват за криптиране и декриптиране. 

Тези два ключа винаги се генерират по двойки: публичен (public) ключ и секретен (частен, private key) ключ. 
Идеята е, че ако се притежава един от двата ключа, е невъзможно да се възпроизведе вторият ключ.

Остава открит въпроса: А ако е възможно да се получи достъп до двата ключа?

Но да се върнем на електронен подпис. 

Да предположим, че някой иска да подпише документ с помощта на EDS. 
Той генерира два ключа за себе си: публичен и частен. 
След това генерира на база стандартен криптопримитив хеш на документа и го криптира със своя секретен ключ. 
Възможно е, разбира се, да се шифрова целият документ, но това не се прави с аргументът, че  файлът, получен в резултат на такова криптиране, може да бъде много голям и за това трябва да се шифрира хеша. 

Файлът, получен в резултат на такова криптиране, ще бъде това, което се определя като електронен подпис. 
Това е отделен файл, който се нарича detach. Той не е документа, който подписваме и се съхранява отделно от него. 
Тази опция е удобна с това, че файл, подписан с отделен EDS, може да бъде прочетен без да се изисква дешифриране.

Какво се изпраща, когато се изпраща подписан с електронен подпис документ?

На практика се изпращат три отделни файла както следва:

Оригиналният документ, 
Електронният подпис на документа;
Публичният ключ. 

Какво следва?

Получателят на документа:

Генерира хеш функция с помощта на стандартен алгоритъм;
дешифрира електронния подпис с помощта на получения публичнен ключ;
гарантира, че хешът съвпада с полученият в резултат на декриптирането електронен подпис (т.е. документът не е променян или редактиран). 

Тази процедура обаче е изключително уязвима и за това се предприемат редица мерки.

Една от най-разпространените е в използването на услугите на специален акредитиран удостоверителен център, който подписва публичния ключ на потребителя с неговия електронен подпис (като предварително е прикачил личните си данни към ключа на потребителя). 
По този начин се сертифицира публичния ключ на потребителя. 

Удостверявването се извършва посредством дешифриране на сертификат (най-често онлайн, с помощта на публичния ключ , предопставен от удостоверителния център).
Това, което гарантира тази процедура е само и единствено, че този ключ принадлежи на конкретен потребител.
На практика имаме удостверителна, а не защитна процедура.

[Avatara]

ЗАЩО ИЗПОЛЗВАНЕТО НА ЕЛЕКТРОНЕН ПОДПИС НЕ Е ЗАЩИТА НА ЦИФРОВИ ДАННИ?

(и защо според стандартите то не бива да се разглежда като защита)

 

Както бе споменато в предходния пост, съгласно дехстващите стандарти, основното предназначение на електронният подпис е удостверяване, а не защита.

За съжаление все по-често ставаме свидетели, как записаното в действащите стандарти бива грубо пренебрегвано.

Последиците от несъблюдаване на предписанията биха могли да бъдат катастрофални и примерите от последните десетилетия нееднозначно доказват това.

 

Нека разгледаме един конкретен пример, който нагледно обяснява защо е важно внимателно да се четат стандартите и защо те би следвало да се изпълбяват.

 

ПРИМЕР:

<!DOCTYPE html>
<html>
<head><meta charset="utf-8"></head>
<body>

<label for="doc">Upload document file</label>
<input id="doc" type="file" onChange="readDoc('doc')">

<label for="sig">Download the signature file</label>
<input id="sig" type="file" onChange="readDoc('sig')">

<button type="button" disabled onClick="check()">Check</button>
<output></output>

<script src="openpgp.min.js"></script>
<script src="validate.js"></script>

</body>
</html>

 

Следващата стъпка е да напишем един малък скрипт, а който ще използваме библиотеката openpgp.min.js. В този случай ще използваме библиотека, която е достъпна от 1999 год., а именно GNU Privacy Guard (GnuPG, или GPG).

"use strict";
let cont   = {doc:'', sig:''},
    flag   = {doc:false, sig:false},
    pubkey = '',
    mess   = '';

// Reading document files (as binary),
// key and signature (as text)

const readDoc = contKey => {
    let reader = new FileReader();
    reader.onload  = async e => {
        cont[contKey] = contKey == "sig" ?
                        e.target.result :
                        new Uint8Array(e.target.result);
        flag[contKey] = true;
        pubkey = await (await fetch("public.key")).text();   
        if (flag["doc"] && flag["sig"])
            document.querySelector("button").disabled = false;
    }
    reader.onerror = err => alert("File read error");

    let fileObj = document.querySelector(`#${contKey}`).files[0];
    if (contKey == "sig") reader.readAsText(fileObj);
    else                  reader.readAsArrayBuffer(fileObj);
}

// Signatures verification

const check = async () => {
    try {   
       const verified = await openpgp.verify({
           message:    openpgp.message.fromBinary(cont["doc"]),
           signature:  await openpgp.signature.readArmored(cont["sig"]),
           publicKeys: (await openpgp.key.readArmored(pubkey)).keys
       });

       const {valid} = verified.signatures[0];

       mess = "The electronic signature is NOT authentic!";

       if (valid) mess = "The electronic signature is authentic.";

    } catch(e) {mess = "The signature file is not in a valid format.";}
    document.querySelector("output").innerHTML = mess;
}

Какво постигнахме с този скрипт?

На практика преодоляхме всички защити и изисквания, записани в следните документи:

ЗАКОН ЗА ЕЛЕКТРОННИЯ ДОКУМЕНТ И ЕЛЕКТРОННИТЕ УДОСТОВЕРИТЕЛНИ УСЛУГИ (ЗАГЛ. ИЗМ. - ДВ, БР. 85 ОТ 2017 Г.)

FIPS PUB 186-4
NIST 800-57, стр. 62–63

ISO 17090-4-2016
ISO 13008-2015
ISO-19005-2:2011

ГОСТ Р 7.0.97-2016

 

Забележка: Така посоченият пример се публикува с учебна цел. Всяко негово изпоплзване за други освен посочената цел е наказуемо и се преследва от закона.

 

Както може да се види от така посочения пример, електронния подпис не защитава. По стандарт, той само и единствено удостверява и с това се изчерпват неговите функции.

Защитата на цифрови данни, която е обект на т.н. "информационна сигурност" (която често се бърка с "кинбернетичната сигурност") е обект на отделни разглеждания.

 

 

Примерна диаграма на един от множеството съвременни варианти за решаване на проблемите с оторизацията и цифровото подписване.

Редактирано Юли 2 от Avatara