|
Kриптиране в Oracle Database 10g |
|
|
|
|
Автор Мариета Димитрова
|
|
понеделник, 09 април 2007 |
Oracle Database 10g предлага изключително добри възможности за защита на данните.
В криптографията под "криптиране" разбираме процеса по разбъркването на дадена информация, така че тя да е неразбираема без определено допълнително познание. Информацията, която "разбъркваме" обикновено се нарича "открит текст", а резултатът от нейното изпълнение - шифрограма. Шифрограмата съдържа всичката информация от открития текст, но в неразбираем вид (поне докато не притежаваме допълнителното познание). Допълнителното познание, което често се нарича "ключ" и се използва както в процеса на криптиране, така и при декриптирането (т.е. получаване на открития текст от шифрграмата. При всеки процес на криптиране съществува алгоритъм, който ясно обяснява как да разбъркаме открития текст, така че от него да се получи шифрограма.
Самият алгоритъм за криптиране, който описва прилагането на ключа към открития тескт с цел получаване на шифрограмата обикновено е публично достояние. Защитата, на която се разчита е самият ключ. Колкото по-дълъг е ключът, толкова по-трудно е той да бъде налучкан. По тази причина при повечето алгоритми по-голям ключ означава по-висока сигурност (но и повече изчисления в процеса на криптиране/ декриптиране).
Като цяло съществуват две големи групи алгоритми за криптиране: тези, които използват един и същ ключ за криптиране и декриптиране (криптография със симетричен ключ) и такива, които са различни за двата процеса (криптография с асиметричен ключ). Oracle Database поддържа алгоритми със симетрични и асиметрични ключове.
Алгоритми за криптиране в Oracle Database 10g
Съществуват различни алгоритми за криптирне (т.е. различни начини за прилагане на ключа към данните за получаването на шифрограмата). В Oracle Database е включен пакет наречен DBMS_CRYPTO, който предоставя готова имплементация на алгоритмите DES, TDES, AES, RC4 и 3DES_2KEY. Последният е включен за съвместимост с по-стари версии и Oracle не препоръчва неговото използване.
Data Encryption Standard (DES)
DES е алгоритъм разработен в началото на 70-те години и бързо се
разпространява, като през 1976 е одобрен като държавен стандарт в САЩ.
Към момента алгоритъмът не се счита за особено сигурен, най-вече заради
малката дължина на ключа му (56 бита). Тъй като разработката на
алгоритъма протича под надзора на Националната агенция за сигурност
(NSA), широко разпространени са слуховете за оставена "задна вратичка"
в него, така че агенцията лесно да дешифрира информация криптирана с
DES.
Tripple DES (TDES)
TDES, наричан също така и
TDEA (Tripple Data Encryption Algorithm) не е нищо повече от DES, но
приложен три пъти върху открития текст. TDES е създаден след
справедливо отправените критики към DES и използва 168 битов ключ (3х56
бита за трите прилагания, но поради податливост на алгоритъма към
определен вид дешифрираща атака ефективността му всъщност е като от
използването на 112 битов ключ). Алгоритъмът все още се използва широко
в различни комуникационни решения, но тъй като изисква доста изчисления
се счита за твърде бавен и обикновено се реализира хардуерно.
Advanced Encryption Standard (AES)
AES е съвременен алгоритъм за шифроване, стандартизиран през 2001г от
Националния институт по стандарти и технологии в САЩ след 5 годишна
процедура. Шифърът използва 128, 192 или 256 битови ключове. До момента
на писането на тази статия няма успешна атака срещу шифъра (с
изключение на атаки базирани на лоша имплементация на алгоритъма). AES
се счита за достатъчно сигурен, за да се шифрова с него класифицирана
правителствена информация в САЩ.
Rivest Cipher 4 (RC4)
RC4 е потоков шифър (който криптира открития текст знак по знак, за
разлика от блоковите шифри, които работят с по-големи порции данни)
широко използван в различни комуникационни протоколи като SSL и WEP.
Като цяло не се счита особено сигурен заради някои успешни атаки срещу
него (като например тази срещу използването му в безжичните мрежи
802.11).
Режими на използване
Вече
споменахме, че при блоковите шифри откритият текст се криптира на равни
блокове. Процесът по свързване на различните криптирани блокове може да
се реализира по няколко начина. Една интересна идея например е да
направим шифрования блок зависим не само от алгоритъма и от ключа, но и
от предходните вече шифровани блокове. Oracle Database поддържа точно
четири вида режима - CBC, CFB, ECB, OFB.
Cipher Block Chaining (CBC)
Режим на блоковата верига (CBC) се реализира като всеки нов блок преди
шифроването си се прилага към предходния (вече шифрован блок) чрез
операция "изключващо или" (XOR). За първият блок от съобщението, за
който не разполагаме с предходен се използва специален блок наречен
"инициализиращ вектор".
Cipher feedback (CFB)
Режимът с обратна връзка е почти идентичен със CBC режимът, но
реализира само-синхронизиращ се потоков шифър. Тук отново се използва
"изключващо или", но при този режим криптирането е на порции по-малки
от размера на блока (произволен брой битове). По този начин той е
подходящ при предаването на поточни данни (например мултимедия) и
изобщо когато се търси ниска латентност между пристигащите и
обработените данни.
Electronic codebook (ECB)
Режимът на електронна кодова книга е познат още като "стандартен режим
на използване". При него отделните блокове нямат никаква връзка по
между си. Негов голям недостатък е, че тъй като блоковете не зависят
един от друг то два еднакви блока открит текст ще бъдат еднакви и след
шифроването си, което може много да улесни атаките срещу шифъра. Плюс
от използването на този режим е, че блоковете могат да се шифроват
непоследователно (например няколко блока от началото на открития текст,
после няколко от края му и така нататък)
Output Feedback (OFB)
Режимът с вътрешна обратна връзка е много близък до CFB, но ключовата
разлика е, че блокът който се прилага с "изключващо или" към открития
текст се генерира независимо както от открития така и от шифрования
текст. OFB също реализира потоков шифър.
Уплътняване на блоковете
Тъй като при блоковите шифри открития текст се разделя на равни
блокове, то можем да предположим че последният блок не винаги ще е
запълнен до крайния си капацитет. Тъй като това може да доведе до лоши
последици за използвания алгоритъм (който очаква пълен блок) са
разработени различни техники за справяне със ситуацията.
Един
от подходите е празните места да се заместват с нули, но това може да
помогне при атаки срещу шифъра (този който го декодира може да се
досети, че крайните стойности в последния блок са нули в открития текст
и да използва тази слабост по някакъв начин). Стандартът PKCS1 #5
препоръчва интересен начин за допълване и той се състои в това да
запълним празните места със стойност съответстваща на броя им. Да
вземем за пример 16 байтов блок, от който само 11 байта ще бъдат
запълнени. Остават 5 байта излишни, затова ги запълваме със стойността
5. Ако в 8 байтов блок, останат 3 свободни позиции – запълваме ги с
числото 3 и т.н. Повече информация за PKCS #5 може да се намери в RFC
2898.
Oracle Database поддържа допълване както с нули, така и съгласно PKCS #5.
Други технологии свързани с криптирането
След като знаем различни алгоритми и техните режими на използване нека
обърнем внимание на няколко допълнителни аспекта от сигурното предаване
на шифрована информация. Първото, с което ще се заемем е
подсигуряването на автентичността на съобщението.
Криптиране и хеш функции
Как да сме сигурни, че едно изпратено съобщение е автентично? За да се
убедим, че то не е било неправомерно променено по пътя най-често се
използва метод за изчисляване чрез хеш функции.
Общо казано хеш
функцията е алгоритъм, чрез който създаваме цифров отпечатък на
произволен тип данни. Функцията трябва да бъде така подбрана, че да не
генерира едни и същи отпечатъци за различните входни данни в допустимия
за нея интервал. Иначе казано, за всички възможни входни данни,
функцията трябва да генерира уникални отпечатъци. Стойностите, които се
получава от хеш функцията обикновено са с фиксирана дължина. Ключовият
момент при хеш функциите е, че те не са обратими. Не можем да получим
входните данни на базата на цифровия отпечатък.
Тъй като промяната на дори един знак във входните данни води цялостна
промяна в цифровия отпечатък, в криптографията хеш функциите широко се
използват най-вече за проверка на идентичността и цялостта на
съобщенията. Oracle Database поддържа три криптографски хеш алгоритъма
– MD4, MD5 и SHA-1.
MD4 (или Message Digest algorithm 4) е
алгоритъм имплементиращ криптографска хеш функция, използвана основно
за проверка на интегритета. Тя генерира 128 битови (16 байта) хеш
стойности. MD5 е наследник на MD4, описан подробно в RFC 1321 и
гарантира, че не само две съобщения е невъзможно да получат идентични
цифрови отпечатъци, но и че е невъзможно да "нагласим" някакво
съобщение така, че да получим точно определен цифров отпечатък.
SHA-1 е алгоритъм от цяла група известна като SHA (Secure Hash
Algorithm) и разработена от Национална Агенция по Сигурност в САЩ
(National Security Agency). SHA-1 генерира 160 битов отпечатък от
съобщение с максимална дължина от 264 бита и използва общи принципи с
MD5. Често SHA-1 се посочва за бъдещ наследник на MD5.
Код за автентичност на съобщението
Видяхме, че използвайки хеш функциите можем да осигурим интегритета на
съобщението (т.е. да сме сигурни, че то не е променено по пътя до нас).
Разбира се, винаги остава вероятността използвания хеш алгоритъм да
бъде открит, съобщението променено и неговата хеш стойност да бъде
преизчислена. Прикрита по този начин намеса практически става
неоткриваема.
За да реши този проблем в криптографията се
използва т.н. "код за автентичност на съобщението" или MAC1. Идеята в
случая е да изчислим някаква стойност не само на базата на съобщението,
но и да използваме допълнителен секретен ключ. Този ключ притежава
както изпращача, така и получателя. Ако някой промени съобщението по
пътя, то той няма да може да изчисли MAC стойността, тъй като дори и да
знае алгоритъма няма да притежава този допълнителен ключ.
Като
цяло MAC алгоритмите могат да се изграждат на базата на хеш функции
(такъв пример е HMAC) или чрез алгоритми за блоково шифриране (например
OMAC, или пък използващият режим на блоковата верига CBC-MAC).
Oracle Database 10g поддържа два вида HMAC алгоритми, които според хеш
функцията използвана от тях са именувани HMAC_MD5 (използващ MD5) и
HMAC_SH1 (използващ SHA-1).
За целите на криптирането в Oracle Database 10g съществува отделен
PL/SQL пакет, който се нарича DBMS_CRYPTO. Освен възможността да
криптираме и декриптираме стандартни типове данни, чрез този пакет
можем да използваме LOB полета (изображения, звук и т.н.). Друга
изключително важна възможност е вградената поддръжка за криптиране и
декриптиране на данни в бази с различен character set.
Криптиране чрез DBMS_CRYPTO
За да криптираме
дадена информация, трябва предварително да вземем някои решения за
алгоритъма, режима на използване и разбира се – ключа.
Използване на хеш функции
За изчисляване на
хеш стойности в DBMS_CRYPTO е включена функция HASH. Тя приема входящи
данни от тип RAW, CLOB или BLOB. Вторият параметър на HASH е типът на
хеширащата функция, който се задава чрез вече описаните константи
дефинирани в DBMS_CRYPTO. Функцията връща RAW стойност, която представя
изчислената хеш стойност.
Съхраняване на ключа и други защитни стратегии
Съхраняването на ключовете е може би най-отговорната задача от процеса
по шифриране на данни. Ако неоторизиран потребител получи достъп до
ключа, то всички наши усилия за защита на данните стават напразни.
Първото и може би най-логично, но определено не най-сигурно място за
съхраняване на ключовете е операционната система, където е инсталирана
базата. Тъй като PL/SQL принципно може да прави външни извиквания,
съвсем лесно можем да реализираме схема с външен файл съдържащ ключ.
Разбира се, имайки предвид че повечето пробиви в сигурността стават
именно на ниво операционна система, съхраняването на ключовете в лесен
за достъп файл направо се равнява на подарък за нарушителя.
По-логично място за съхранение е самата Oracle базата. Можем да
съхраняваме ключовете в отделна таблица (като цяло лоша идея), до която
имат достъп само определени потребители, а можем също така и да оставим
фиксиран ключ в самите PL/SQL процедури които се грижат за криптирането
и декриптирането на данните.
Ако изберем втория вариант,
задължително трябва да "скрием" кода на процедурата, така че ключът да
не може да се чете в свободен вид. Това можем да направим, като
използваме wrap инструмента, който е част от Oracle Database 10g. Това,
което той прави е от чистият текст да генерира не четим байт код. По
този начин никой разработчик, администратор или потребител имащ достъп
до базата не може да види изходния код на процедурата, съдържаща ключа.
Въпреки, че по този начин съдържанието на файла няма да е четимо, то ще
продължава коректно да се изпълнява. Разбира се, ще загубим
възможността да го променяме, така че е добре да си запазим копие извън
машината (например на външен носител с надлежно контролиран достъп).
Разбира се, не трябва да забравяме, че никой не гарантира нивото на
сигурност, което wrap дава. Колкото по-далеч съхраняваме ключа от
самите данни, толкова по-добре.
Възможно е да приложим
стратегия, при която самите потребители управляват ключовете на данните
си. Имайки предвид обаче, че много от потребителите използват меко
казано неадекватни практики що се касае до сигурността, към тази
стратегия трябва да се подхожда изключително внимателно. Още повече,
повечето експерти по сигурността посочват периодичната промяна на
криптиращите ключове като добра практика (с други думи да декриптираме
и отново да криптираме данните но с нов ключ, прилагайки процедурата
през определен период от време). Дистрибуцията и съхранението на новите
ключове от потребителите също е рискова операция, имайки предвид
навиците за записване на пароли на хвърчащи листчета.
Може би
най-лесният и сигурен начин е използването на Transparent Data
Encryption (или TDE), това е възможност, която присъства в Oracle
Database 10g Release 2 и автоматично управлява не само процесите по
криптиране и декриптиране, но и съхранението на ключовете. Тъй като
тази система сама по себе си е достатъчно сложна, ще я разгледаме
подробно по-нататък.
След като разгледахме няколко възможни
варианта, може би все пак трябва да помислим за някаква обща препоръка
за стратегия спрямо ключовете. Може би един от най-добрите варианти,
които максимално ще затруднят всеки нарушител включва по малко от
всички разгледани варианти, а именно:
1.не използваме един единствен ключ – вместо това за всеки запис от таблицата генерираме отделен ключ;
2.не криптираме данните с ключовете в таблицата, а вместо това за всеки
ред правим комбинация от един главен (и таен) ключ и специално
генерираният за реда ключ (например чрез "изключващо или" - XOR)
3.главният ключ съхраняваме извън системата и го предаваме като
параметър на криптиращите и декриптиращи процедури. в този случай
трябва да сме сигурни че никой няма да "подслуша" предаването на
параметъра.
Използвайки подобна стратегия можем да сме сигурни,
че за декриптирането на данните един нарушител трябва да се добере и до
двата ключа едновременно, което ще го затрудни допълнително. Ако
желаем, като допълнителна мярка можем да си "поиграем" с Oracle Label
Security спрямо колоната в таблицата съдържащ уникалните ключове за
записите. Изобщо – вариантите са много. Въпросът е да открием правилния
баланс между високата надеждност и лекотата за работа с данните и
обслужването на системата.
Заключение
Oracle Database 10g предлага изключителни добри възможности за защита
на данните. Това, за което трябва да се погрижим е да ги използваме
правилно. Също така, заслужава си да погледнем и малко по-далече от
стандартните възможности за криптиране. Oracle предлага допълнителна
опция към базата, наречена Oracle Advanced Security, която включва
възможности за криптиране на мрежово ниво (при преноса на данни между
различни сървъри и между клиент и сървър), спомената вече Transparent
Data Encryption, както и Strong Authentication системата, чрез която
автентикацията на потребителите се извършва не само на базата на
пароли, а и чрез смарт карти, сертификати и други.
За повече информация: http://manchev.org/cms/index.php?option=com_content&task=view&id=42&Itemid=29
|
|
Последна промяна ( вторник, 24 април 2007 )
|
|
|
