VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS
OVĚŘENÍ UŽIVATELŮ POMOCÍ CHYTRÝCH TELEFONŮ
DIPLOMOVÁ PRÁCE MASTER'S THESIS
AUTOR PRÁCE AUTHOR
BRNO 2014
Bc. DAVID BĚLÍK
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS
OVĚŘENÍ UŽIVATELŮ POMOCÍ CHYTRÝCH TELEFONŮ USER VERIFICATION BASED ON SMART-PHONES
DIPLOMOVÁ PRÁCE MASTER'S THESIS
AUTOR PRÁCE
Bc. DAVID BĚLÍK
AUTHOR
VEDOUCÍ PRÁCE SUPERVISOR
BRNO 2014
Ing. JAN HAJNÝ, Ph.D.
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací
Diplomová práce magisterský navazující studijní obor Telekomunikační a informační technika Student: Ročník:
Bc. David Bělík 2
ID: 106369 Akademický rok: 2013/2014
NÁZEV TÉMATU:
Ověření uživatelů pomocí chytrých telefonů POKYNY PRO VYPRACOVÁNÍ: Téma je zaměřeno na využití tzv. chytrých telefonů v oblasti bezpečné autentizace a autorizace uživatelů elektronických služeb. Student se ve své práci zaměří na možnosti implementace kryptografických protokolů na platformě Android a iOS. Výstupem bude návrh bezpečnostní aplikace a její experimentální implementace využívající Secure Elements, NFC či dvojrozměrné kódy pro přenos dat. Důraz bude kladen na praktickou funkčnost aplikace, a to jak na její mobilní, tak serverovou část. DOPORUČENÁ LITERATURA: [1] STALLINGS, William. Cryptography and Network Security: Principles and Practice (5th Edition). USA : Prentice Hall, 2010. 744 s. ISBN 0136097049. [2] IOS Security. [online]. 2012 [cit. 2012-10-09]. Dostupné z: http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf. Termín zadání:
10.2.2014
Termín odevzdání:
28.5.2014
Vedoucí práce: Ing. Jan Hajný, Ph.D. Konzultanti diplomové práce:
prof. Ing. Kamil Vrba, CSc. Předseda oborové rady
UPOZORNĚNÍ: Autor diplomové práce nesmí při vytváření diplomové práce porušit autorská práva třetích osob, zejména nesmí zasahovat nedovoleným způsobem do cizích autorských práv osobnostních a musí si být plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení části druhé, hlavy VI. díl 4 Trestního zákoníku č.40/2009 Sb.
Abstrakt Cílem diplomové práce je seznámit se s oblastí bezpeþné autentizace a autorizace uživatelĤ v chytrých telefonech na platformČ Android. V kapitolách jsou popsány jednotlivé typy šifrování, autentizací, autentizaþních mechanismĤ a vlastnosti QR kódĤ. V praktické þásti jsou vytvoĜeny aplikace s implementovaným autentizaþním schématem, které je vyvíjeno na FEKT VUT v BrnČ. Je vytvoĜena jak klientská þást aplikace, která generuje QR kód, tak i serverová þást, která ovČĜuje jejich pravost dat.
Klíþové slova QR kód, autentizace, kryptografie, hash, Android, implementace
Abstract The main aim of this diploma thesis is to get acquainted with the area of secure authentication and authorization of users in smartphones on the Android platform. Individual types of encoding, authentications, authentication devices and characteristics of QR codes are decribed in the chapters. In the practical part of this thesis the applications are created with an implemented authentication scheme, which is being developed at FEKT VUT in Brno. The client part of the application, that generates QR code, as well as the server part, that verifies the authenticity of the data, are set up. .
Keywords
QR code, authentication, hash, cryptography, Android, implementation
BċLÍK, D. OvČĜení uživatelĤ pomocí chytrých telefonĤ. Brno: Vysoké uþení technické v BrnČ, Fakulta elektrotechniky a komunikaþních technologií, 2014. 58 s. Vedoucí diplomové práce Ing. Jan Hajný, Ph.D.
Prohlášení Prohlašuji, že svou diplomovou práci na téma „OvČĜování uživatelĤ pomocí chytrých telefonĤ“ jsem vypracoval samostatnČ pod vedením vedoucího diplomové práce a s použitím odborné literatury a dalších informaþních zdrojĤ, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené diplomové práce dále prohlašuji, že v souvislosti s vytvoĜením této diplomové práce jsem neporušil autorská práva tĜetích osob, zejména jsem nezasáhl nedovoleným zpĤsobem do cizích autorských práv osobnostních a/nebo majetkových a jsem si plnČ vČdom následkĤ porušení ustanovení § 11 a následujících zákona þ. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zmČnČ nČkterých zákonĤ (autorský zákon), ve znČní pozdČjších pĜedpisĤ, vþetnČ možných trestnČprávních dĤsledkĤ vyplývajících z ustanovení þásti druhé, hlavy VI. díl 4 Trestního zákoníku þ. 40/2009 Sb.
V BrnČ dne …………………
.......................................... podpis autora
PodČkování DČkuji vedoucímu práce Ing. Janu Hajnému, Ph.D. za velmi užiteþnou metodickou pomoc a další cenné rady pĜi zpracování mé diplomové práce.
V BrnČ dne …………………
.......................................... podpis autora
Faculty of Electrical Engineering and Communication Brno University of Technology Technická 12, CZ-61600 Brno, Czechia http://www.six.feec.vutbr.cz
.
KďƐĂŚ ^ĞnjŶĂŵŽďƌĄnjŬƽ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϴ Úvod͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϬ 1.
Úvod do kryptografie͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϭ 1.1.
Modulární aritmetika͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϮ
1.2.
Symetrická kryptografie͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϯ
1.3.
Asymetrická kryptografie͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϰ
ϭ͘ϯ͘ϭ͘ 1.4. 2.
ƵƚĞŶƚŝnjĂĐĞnjŶĂůŽƐƚş͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϳ
Ϯ͘ϭ͘Ϯ͘
ƵƚĞŶƚŝnjĂĐĞǎĂĚĂƚĞůĞŵ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϴ
2.1.3.
ƵƚĞŶƚŝnjĂĐĞƉƎĞĚŵĢƚĞŵ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϵ
Autentizaþní protokoly͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϭ Protokol Radius͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϭ
ϯ͘ϭ͘ϭ͘
&ƵŶŬĐĞƉƌŽƚŽŬŽůƵ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϮϮ
ϯ͘ϭ͘Ϯ͘
&ŽƌŵĄƚƉĂŬĞƚƵ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϰ
3.2.
SchnorrĤv podpis͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϲ
QR kódy͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϴ 4.1.
Princip a vlastnosti͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϵ
ϰ͘ϭ͘ϭ͘
<ĂƉĂĐŝƚĂ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϵ
ϰ͘ϭ͘Ϯ͘
^ƚƌƵŬƚƵƌĂ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϵ
ϰ͘ϭ͘ϯ͘
<ŽƌĞŬĐĞĐŚLJď͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϭ
4.2. 5.
Typy autentizace͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϳ
Ϯ͘ϭ͘ϭ͘
3.1.
4.
Hash funkce͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϲ
Autentizace͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϲ 2.1.
3.
ŝŐŝƚĄůŶşƉŽĚƉŝƐ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϱ
Generátor a þteþka QR kódu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϭ
Operaþní systém Android͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϮ
-6-
6.
7.
5.1.
Historie͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϮ
5.2.
Architektura͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϮ
Vývojové prostĜedí Eclipse͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϰ 6.1.
Instalace ADT͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϱ
6.2.
Instalace SDK͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϲ
6.3.
AVD Manager͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϲ
Implementace kryptografického protokolu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϴ 7.1.
O schématu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϴ
7.2.
Souþasný stav revokaþních technik͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϵ
7.3.
Schéma atributového ovČĜení͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϬ
7.4.
Implementace autentizaþního schématu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϮ
ϳ͘ϰ͘ϭ͘
ƉůŝŬĂĐĞůŝĞŶƚ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϯ
ϳ͘ϰ͘Ϯ͘
ƉůŝŬĂĐĞsĞƌŝĨŝĞƌ͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϳ
ZávČr͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϮ Seznam použité literatury͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϯ Seznam zkratek͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϲ Seznam pĜíloh͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϴ
-7-
õ Obrázek ϭ Schéma symetrické kryptografie͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϯ Obrázek Ϯ Schéma asymetrické kryptografie͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϰ Obrázek ϯ Princip digitálního podpisu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϱ Obrázek ϰSchéma Ĝízeného pĜístupu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϭϳ Obrázek ϱ Architektura autentizátoru [12]͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϮϬ Obrázek ϲ Zamítnutí požadavku [21]͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϯ Obrázek ϳ Povolení pĜístupu [21]͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϯ Obrázek ϴ Radius paket͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϰ Obrázek ϵ Struktura atributu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϱ Obrázek 10 Schéma Schnorrova protokolu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϳ Obrázek ϭϭ Ukázka QR kódu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϴ Obrázek ϭϮ Kapacita QR kódu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϵ Obrázek ϭϯ Struktura finder pattern͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘Ϯϵ Obrázek ϭϰ Struktura Alegnment patern͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϬ Obrázek ϭϱ Struktura QR kódu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϬ Obrázek 16 Architektura OS͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϯ Obrázek 17 Uživatelské prostĜedí programu Eclipse͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϰ Obrázek 18 Instalace ADT͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϱ Obrázek 19 Instalace SDK͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϲ Obrázek 20 Ladící režim͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϳ Obrázek Ϯϭ AVD Manager͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϯϳ Obrázek 22 Schéma atributového ovČĜení͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϭ Obrázek 23 Autentizaþní protokol͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϮ Obrázek 24 Test - ovČĜení protokolu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϲ
-8-
Obrázek 25 Aplikace Client͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϲ Obrázek 26 Aplikace Verifier - þasová tolerance͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϵ Obrázek 27 Aplikace Verifier - základní obrazovka͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϰϵ Obrázek 28 Aplikace Verifier - skenování QR kódu͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϬ Obrázek 29 Aplikace Verifier - správné ovČĜení͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϬ Obrázek 30 Aplikace Verifier - chybné ovČĜení͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘͘ϱϭ
-9-
Úvod Cílem diplomové práce je seznámit se s oblastí bezpeþné autentizace a autorizace uživatelĤ v chytrých telefonech. Práce je zamČĜena na implementaci kryptografického protokolu na platformu Android od spoleþnosti Google. V první kapitole jsme obeznámeni s kryptografií, kde je popsána modulární aritmetika a symetrická a asymetrická kryptografie. V asymetrické kryptografii je poté popsána funkce digitálního podpisu. V poslední þásti první kapitoly je popsána hashovací funkce. Druhá kapitola se vČnuje autentizaci. Ta je rozdČlena do tĜí kategorií: autentizace znalostí, autentizace žadatelem a autentizace pĜedmČtem. TĜetí kapitola popisuje autentizaþní mechanismy. V této kapitole jsou popsány dva autentizaþní mechanismy. Prvním je protokol Radius. Je zde popsána jeho funkce a formát paketu. Druhým popsaným mechanismem je SchnorrĤv podpis. ýtvrtá kapitola je vČnována QR kódĤm. V zaþátku kapitoly je popsán princip QR kódu a jeho vlastnosti. Poté je popsána jeho struktura a kolik dat je možno do QR kódu uložit. V další podkapitole je popsána korekce chyb. ZávČrem þtvrté kapitoly jsou popsány generátory a druhy þteþek QR kódu. Pátá kapitola popisuje vybraný operaþní systém Android. Jsou zde popsány poþátky operaþního systému pro mobilní telefony a jeho architektura. Šestá kapitola se vČnuje vývojovému prostĜedí Eclipse, ve kterém je vyvíjena aplikace praktické þásti této diplomové práce. Je zde popsána instalace softwaru a potĜebných doplĖkĤ ke správné funkci vývojového prostĜedí vþetnČ virtuálního zaĜízení. Na tomto zaĜízení je možné testovat vytvoĜené aplikace. Poslední kapitola tvoĜí praktickou þást diplomové práce. Popisuje implementaci zadaného autentizaþního schématu. Dále obsahuje popis dvou vytvoĜených aplikací. Jedná se o klientskou þást a serverovou þást.
- 10 -
1. Úvod do kryptografie VČdu o využívání matematických funkcí pro šifrování a opČtovné získání dat, která se rovnČž zamČĜuje na návrh šifrovacích algoritmĤ, mĤžeme oznaþit jako kryptografii. Uchovávání tajných informací, zajišĢování dĤvČrnosti chránČných dat a jejich distribuce po nezabezpeþeném médiu jsou hlavními úkoly tohoto odvČtví bezpeþnosti. Samotné slovo kryptografie pochází z Ĝeckých slov kryptós (= skrytý) a gráphein (= psát). NČkdy je pojem obecnČji používán pro vČdu o þemkoli spojeném se šiframi jako alternativa k pojmu kryptologie. Kryptologie zahrnuje kromČ kryptografie také kryptoanalýzu, neboli luštČní zašifrovaných zpráv. Zpráva pĜed zašifrováním (otevĜený text) je podle pĜedem dohodnutých pravidel odesílatele a pĜíjemce pozmČnČna na šifrový text, aby nedošlo ke zneužití jejího obsahu. V pĜípadČ získání takto zmodifikované zprávy útoþníkem je její odhalení bez znalosti pĜesných pravidel pro dešifrování velmi obtížné, v závislosti na použité technologii ve vČtšinČ pĜípadĤ však nemožné. Data, které jsou chránČny šifrovacími prostĜedky, by nemČl mít možnost nikdo pĜeþíst ani pĜi nasazení nejmodernČjších výpoþetních systémĤ pro jejich vyluštČní. Bezpeþnost množství algoritmĤ v minulosti byla založena na jejich dokonalém utajení, avšak problém nastal právČ tehdy, pokud se prozradil princip þinnosti algoritmu. Z tohoto dĤvodu se v souþasnosti prosazuje trend zveĜejĖování všech kryptografických algoritmĤ. Bezpeþnost algoritmĤ je tedy založena na pĜedpokladu matematické nároþnosti Ĝešit úkoly v reálném þase, a ne na dĤsledném utajení. Také zveĜejnČný algoritmus pĤsobí dĤvČryhodnČji a každý má možnost zkontrolovat jeho kvalitu [16, 17].
- 11 -
1.1. Modulární aritmetika V této podkapitole je þerpáno z pramenu [1]. Je zde popsána modulární aritmetika. Modulární aritmetikou se rozumí provádČní operace modulo celé þíslo. Víme, že x je reálné þíslo a ہx ۂje nejvČtší celé þíslo menší nebo rovno x a n je kladné celé þíslo [1]. V pĜípadČ, že a je celé þíslo a n je kladné celé þíslo, pak a(mod n) je definováno jako zbytek po dČlení þísla a þíslem n. Pro a platí: a = ہa/n · ۂn + a (mod n).
(1.1)
DvČ þísla a, b jsou kongruentní modulo n, mají-li stejný zbytek pĜi dČlení s þíslem n. Píšeme: a Ł b (mod n).
(1.2)
Kongruence je reflexivní, symetrická a tranzitivní. Pro reflexivitu platí, že a Ł a (mod n) pro a אZ.
(1.3)
Kongruence je symetrická, jestliže a Ł b (mod n) ֜ b Ł a (mod n).
(1.4)
Tranzitivní je v pĜípadČ, že platí a Ł b (mod n) a b Ł c (mod n), potom a Ł c (mod n).
(1.5)
V opaþném pĜípadČ Ĝíkáme, že þísla a, b jsou nekongruentní modulo n. Na základČ relace kongruence se množina celých þísel rozpadá na tĜídy prvkĤ se stejným zbytkem pĜi dČlení þíslem n tzv. zbytkové tĜídy modulo n. Operace sþítání a násobení v Zn jsou provádČny modulo n. Pro každé celé þíslo a platí: [a]n = {x | x Ł a (mod n)}
(1.6)
množina celých þísel kongruentních a modulo n se nazývá množinou zbytkových tĜíd modulo n. Pro souþet a souþin modulo n platí následující tvrzení: • výsledkem a + b je þíslo c אZn, pro které platí a + b Ł c (mod n) • výsledkem a * b je þíslo c אZn, pro které platí a * b Ł c (mod n) Multiplikativní inverzní prvek k prvku a modulo n je þíslo x אZn takové, že a * x Ł 1 (mod n).
- 12 -
(1.7)
Existuje-li þíslo x, je oznaþováno za jednoznaþné. K prvku a modulo n existuje inverzní prvek oznaþován a-1. DČlení je definováno jako souþin þísla a þíslem b modulo n a * b-1 modulo n
(1.8)
jen tehdy, je-li b invertovatelné mod n. Aditivní opaþný prvek k prvku a modulo n je þíslo x אZn takové, že a * x Ł 1 (mod n).
(1.9)
Inverzní prvek k a modulo n budeme oznaþovat -a. K urþení, zda k danému a existuje inverzní prvek, se využívá fakt, že nejvČtší spoleþný dČlitel a, n se rovná jedné. Mezi další vlastnosti modulární aritmetiky Ĝadíme: • [(D (mod Q)) + (E (mod Q))] (mod Q) = (D + E) (mod Q),
(2.0)
[(D (mod Q)) · (E (mod Q))] (mod Q) = (D · E) (mod Q),
(2.1)
• [(D (mod Q)) - (E (mod Q))] (mod Q) = (D - E) (mod Q) [3].
(2.2)
•
1.2. Symetrická kryptografie Symetrická šifra, nČkdy též nazývaná konvenþní, pĜedstavuje metodu šifrování, u které se kódování i dekódování zprávy provádí pomocí stejné hodnoty klíþe. Princip této metody je znázornČn na obrázku 1. Hlavní výhodou tohoto principu komunikace je nízká výpoþetní nároþnost, protože matematické vztahy nejsou tak složité jako u asymetrických šifer. Další výhodou je vysoká pĜenosová rychlost. Hlavní nevýhodou je obtížná poþáteþní výmČna klíþĤ s neznámou stranou a její autentizace.
Obrázek ϭ Schéma symetrické kryptografie Symetrické šifry se dČlí na dva druhy – proudové a blokové. U proudové šifry dochází ke zpracování otevĜeného textu po jednotlivých bitech. Šifrování (dešifrování) se provádí tak, že z klíþe se vygenerují posloupnosti a poté jsou jednotlivé znaky šifrovány odlišnými
- 13 -
transformacemi. Bloková šifra rozdČlí otevĜený text na bloky stejné velikosti a poslední blok doplní vhodným zpĤsobem na stejnou velikost. Šifrování (dešifrování) je provádČno stejnou transformací pomocí šifrovacího klíþe [18, 19]. 1.3. Asymetrická kryptografie Asymetrická kryptografie je šifrovací algoritmus, který využívá pro šifrování a dešifrování dva klíþe. Jedná se o pár klíþĤ, který se skládá z veĜejného a soukromého klíþe. Schéma asymetrické kryptografie je znázornČno na obrázku 2. NejpodstatnČjší vlastností tČchto klíþĤ je, že data zašifrované jedním klíþem z této dvojice mohou být dešifrována pouze a právČ druhým klíþem z toho páru. Omezení platí i pro šifrování a následné dešifrování identickým klíþem, kdy zašifrovaná data jedním klíþem není možné tímto identickým klíþem zpČtnČ dešifrovat. Bezpeþnost asymetrické kryptografie spoþívá v nepĜístupnosti soukromého klíþe a jeho bezpeþného utajení, oproti tomu se veĜejný klíþ poskytuje všem komunikujícím stranám. Pokud uživatel chce komunikovat, musí poskytnout svĤj veĜejný klíþ. Tímto klíþem mu pĜijde zašifrovaná zpráva od komunikujícího na druhé stranČ. Jediný, kdo mĤže tuto zprávu pĜeþíst nebo dešifrovat, je uživatel vlastnící soukromý klíþ z páru klíþĤ, ze kterého byl poskytnut i veĜejný klíþ. Systém tohoto šifrování je založen na matematických problémech, které nepĜinášejí žádné výsledky v polynominálním, ale pouze v exponenciálním þase. Asymetrické šifry vČtšinou pracují se specifickým druhem þísel - s prvoþísly. V dnešní dobČ se pracuje pĜevážnČ s 1024 a 2048 bitovými klíþi a pro dlouhodobČjší úþely je dobré použít klíþ o délce 3072bitĤ. Výhodou tohoto principu komunikace je potĜeba mnohem menšího poþtu klíþĤ, kdy každá osoba vlastní jen jeden pár klíþĤ. Cenu za vyšší bezpeþnost v porovnání se symetrickou kryptologií si na druhou stranu vyžádala vyšší výpoþetní nároþnost algoritmĤ a tím pádem i pomalejší komunikaci [19,20].
Obrázek Ϯ Schéma asymetrické kryptografie
- 14 -
1.3.1. Digitální podpis
Základní myšlenkou digitálního podpisu je obdoba klasického podpisu, jenž má zaruþit jednoznaþnou identifikaci osoby v prostĜedí digitálního svČta, aĢ už pĜi podpisech rĤzných smluv, bankovních transakcích a další. Dalším nutným aspektem pĜi správné komunikaci je zajištČní integrity podepsaného textu. To znamená být schopen odhalit, zda byl daný text nČjakým zpĤsobem pozmČnČn, protože na komunikaþním médiu mĤže teoreticky kdokoliv tuto zprávu pozmČnit. Digitální podpis je vytváĜen pomocí soukromého klíþe asymetrického kryptografického systému a hashovací funkce (viz kapitola 1.4). Jeho správnost je ovČĜována naopak veĜejným klíþem, který tvoĜí spolu se soukromým klíþem také pár klíþĤ. DĤvodem tohoto rozdílu je odlišná potĜeba, protože pĜi podpisu dokumentu chceme, aby si kdokoliv mohl ovČĜit platný podpis. Platný podpis nesmí být schopen vytvoĜit nikdo kromČ oprávnČného þlovČka [3, 4].
Obrázek ϯ Princip digitálního podpisu PĜi elektronickém podepisování se nepracuje s celou zprávou, ale jen s výtahem zprávy (hash). Odesílatel elektronicky podepsané zprávy je jediným vlastníkem soukromého (tajného) klíþe, tak je zaruþena autentiþnost zprávy. OvČĜení digitálního podpisu pak probíhá za použití veĜejného klíþe autora. Spoþívá v nezávislém výpoþtu hashe z dokumentu (hash1) a dešifrování hashe elektronického podpisu pomocí veĜejného klíþe. Tím dostaneme hash2. Pokud se výsledky rovnají (hash1=hash2), tak je zpráva považována za dĤvČryhodnou. PĜi šifrování se používá veĜejný klíþ pĜíjemce zprávy, který je pak jediný, kdo mĤže zprávu pĜeþíst. Princip digitálního podpisu je uveden na obrázku 3.
- 15 -
1.4. Hash funkce Hashovací funkce je matematická funkce pro ovČĜení integrity dat. Hashovací funkce dokáže pĜevést velké množství vstupních dat na pomČrnČ malé výstupní þíslo, tzv. digitální „otisk“ dat. Vstupem takovéto funkce je blok promČnné délky (zpráva) a výstupem je blok pevné délky (vČtšinou 128 nebo 160 bitĤ). Ke své þinnosti nepotĜebuje žádný klíþ. Základním nedostatkem hashování je, že vstupní data mnohonásobnČ pĜevyšují poþet vytvoĜitelných otiskĤ. To neznamená, že pokud se výstupní otisky rovnají, pak se rovnají také vstupní data. Hashovaní funkce se tak snaží minimalizovat shodu otiskĤ na minimum. Kvalitní bezpeþná hashovací funkce musí splĖovat 3 základní podmínky: 1. JednosmČrnost Podmínka toho, že ze vstupního ĜetČzce dat lze vypoþíst jednoznaþný otisk, avšak z otisku nelze zpČtnČ vypoþíst pĤvodní data. 2. Slabá bezkoliznost Není možné ke vstupním datĤm a jejich otisku vypoþíst jiná data se stejným otiskem. 3. Silná bezkoliznost Není možné najít dva rĤzné texty se stejným otiskem. Podmínky jsou považovány za splnČné, pokud jsou splnČny po dostateþnČ dlouhou dobu, tzn. nabourání této funkce je þasovČ a výpoþetnČ velmi nároþné [5, 6, 7].
2. Autentizace Autentizace pochází z nČmeckého Authentisierung. Hlavním cílem autentizace je Ĝízení pĜístupu k nČjaké službČ þi pĜístupu k datĤm. Autentizace tedy slouží k ovČĜování proklamované identity entit (osob, služeb, souborĤ a další). Zda je daná entita ta, za kterou se vydává. Pomáhá nám zamezit pĜístup pĜípadným útoþníkĤm a povolit pĜístup pouze tČm, kteĜí jsou danou firmou þi osobou provČĜeni [8,9]. Schéma Ĝízení pĜístupu autentizace znázorĖuje obrázek 4. Schéma se skládá z žadatele, seznamu, kontroléru a aktiv, kde žadatel je osoba, která žádá o pĜístup k aktivĤm. Seznam obsahuje osoby a služby mající povolený pĜístup k aktivĤm. Kontrolér je osoba, služba nebo
- 16 -
zaĜízení, které provádí porovnání identity se záznamem v seznamu. Data a jiné citlivé informace, pĜípadnČ pĜístup k prostĜedkĤm firmy jsou obsaženy v aktivech [8,9].
Obrázek ϰSchéma Ĝízeného pĜístupu 2.1. Typy autentizace Autentizace se dČlí na fyzickou, kdy jsou identifikaþní údaje žadatele a aktiva kontrolovány nČjakou fyzickou osobou a na základČ jejího rozhodnutí je žadateli povolen pĜístup k aktivĤm, nebo na automatizovanou, kde nejvČtším problémem je ovČĜení, zda se žadatel nevydává za nČkoho jiného. V informatice je proces autentizace zautomatizován. Automatizovaná metoda autentizace pro zajištČní integrity se dá rozdČlit do tĜí þástí [8]: 1. autentizace znalostí 2. autentizace žadatelem 3. autentizace pĜedmČtem V následujících podkapitolách jsou více popsány jednotlivé typy autentizací. 2.1.1. Autentizace znalostí Autentizace pomocí uživatelského jména a hesla je jednou z nejstarších typĤ autentizace. U této autentizace je žadatel pĜed povolením pĜístupu k aktivĤm dotazován na znalost urþité pĜístupové informace. Na základČ pĜístupové informace je žadateli povolen pĜístup. PĜístupovou informaci neboli heslo, by mČl znát pouze autorizovaný uživatel, aby se zamezilo pĜístupu nepovolených osob. Informaci mají uživatelé uloženou ve své pamČti, proto je pĜístupová informace lehce zapamatovatelná. Protože uživatel vČtšinou disponuje hned nČkolika hesly nebo autentizaþními kódy od rĤzných systémĤ, je to pro nČj v dnešní dobČ velmi obtížné. Proto se þasto stává, že si je uživatelé nČkam zapisují, nebo používají stejná,
- 17 -
vČtšinou velmi jednoduchá hesla. Vezmeme-li v potaz další požadavky, které jsou v dnešní dobČ kladeny na hesla: • dostateþná délka, • kombinace malých, velkých písmen, þíslic a interpunkþních znamének, • pro každý kontrolér jiné heslo, • heslo nesmí mít význam, • pravidelná obmČna hesla, zjistíme, že s ohledem na výše zmínČné dĤvody je tento zpĤsob autentizace nedostaþující a tak se zaþal používat v kombinaci s jiným typem. Druhou silnČji chránČnou metodou autentizace znalostí je typ výzva odpovČć. Principem této metody je, že žadatel potvrdí vhodnou odpovČdí kontroléru znalost reakce na jeho výzvu. Bezpeþnost metody je založena na tom, že kontrolér posílá výzvu pouze jednou a nikdy ne stejnou. Poslední metodou je autentizace nulové znalosti (angl. Zero-Knowledge). Touto metodou mĤže žadatel ovČĜovateli dokázat, že data jsou pravdivá i bez pĜedání veškerých informací. Tato metoda zachovává anonymitu uživatele [8,9,11]. 2.1.2. Autentizace žadatelem U autentizace žadatelem se pĜístup povoluje þi zamítá na základČ porovnávání aktuálních charakteristik žadatele s uloženými záznamy, které se v terminálu nacházejí uloženy v kontejnerech, nebo ve formČ certifikátĤ autorizovaných pĜíslušnou autoritou. Základními parametry pro autentizaci žadatele je jeho jedineþnost a nemČnnost dané charakteristiky. KvĤli požadavku na jedineþnost charakteristicky se tento typ používá pouze u osob. Autentizace založené na tČchto údajích se nazývají biometrické metody autentizace [8,10,11,12]. Biometrické metody autentizace mĤžeme rozdČlit do dvou þástí: 1. fyziologické metody, 2. behaviorální metody. Fyziologické metody jsou metody, které se zamČĜují na jedineþné a nemČnné fyziologické charakteristiky þlovČka. PatĜí sem rozpoznání podle: • Otisku prstĤ - využívá individuálnost tvaru papilárních linií. • Obliþeje - autentizovaná osoba se nechá vyfotografovat zepĜedu a získaný portrét se dále zpracovává. Metody dČlíme na obliþejovou metriku (vyhledávají se základní
- 18 -
body tváĜe a mČĜí se vzdálenosti mezi tČmito body) a charakteristiku obliþeje (zjišĢuje se míra shody portrétu s tzv. charakteristickými obliþeji). • Oþní duhovky - rozpoznávají se tvary a rozmístČní skvrn na oþní duhovce. • Geometrie ruky - zkoumají se geometrické tvary ruky a dlanČ. • Oþní sítnice - je založena na individuálních rysech cévního ĜeþištČ oþní sítnice. Behaviorální metody jsou založeny na individuálnosti lidského chování. Metody mĤžeme charakteristicky rozdČlit podle: • Hlasu - využívá specifické charakteristiky Ĝeþníka (napĜ. kadenci Ĝeþi, kmitoþtové spektrum hlasu apod.) pĜi sdČlení nČjaké fráze. • Psaní na klávesnici - je založena na specifických rysech zápisu nČjaké sekvence znakĤ
(napĜ. kadence psaní, délky pauz apod.) [8,10,11,12]. 2.1.3. Autentizace pĜedmČtem U tohoto typu autentizace se využívá možnost uložení autentizaþních dat na speciální záznamové zaĜízení, tzv. token. Jelikož veškeré pĜístupové informace jsou uloženy na zaĜízení v tokenu (þipová karta), je nutné, aby byl daný pĜedmČt zabezpeþen proti padČlání a zároveĖ jej uživatel chránil pĜed krádeží þi ztrátou. Velkou výhodou je, že si uživatel nemusí pamatovat pĜístupovou informaci, která je uložena v token. Proto mĤže být velmi dlouhá bezpeþná. Typy autentizaþních pĜedmČtĤ lze klasifikovat na: • uložištČ: o s nechránČnými daty, o schránČnými daty, • autentizátory. UložištČ je pĜedmČt, kde se autentizaþní data pouze ukládají. Samotná autentizace se provádí na jiném zaĜízení. UložištČ se dČlí na dvČ tĜídy s nechránČnými a chránČnými daty. Z uložištČ s nechránČnými daty lze autentizaþní informaci vyþíst bez jakéhokoliv omezení použitím vhodného þtecího zaĜízení. Naopak u uložištČ s chránČnými daty je použit vyšší stupeĖ ochrany, kdy autentizaþní informace jsou chránČny jednoduchou kryptografickou šifrou, nebo je k jejich vyþtení z pamČti potĜeba znalost hesla, popĜ. klíþe. Autentizátory poskytují v sobČ uloženým informacím nejvyšší možnou ochranu, protože se autentizaþní proces provádí pĜímo v nich a autentizaci vĤþi kontroléru kompletnČ
- 19 -
zajišĢují. Autentizátory (obrázek 5) jsou jednoþipové poþítaþe, které pro vykonávání své þinnosti musí obsahovat proces, pamČĢ, komunikaþní rozhraní a obþas i kryptografický koprocesor, který slouží k provádČní složitČjších kryptografických výpoþtĤ. Jedná se napĜ. o Smartkarty nebo USB tokeny [8,10,11,12].
Obrázek ϱ Architektura autentizátoru [12] Autentizátory podle typu komunikaþního portu dČlíme: • kontaktní mikroprocesorové karty - komunikaþní rozhraní podle standardu ISO/EIC 7816, • bezkontaktní mikroprocesorové karty - komunikaþní rozhraní podle standardu ISO/IEC 14443, •
USB tokeny - komunikaþní rozhraní podle nČkterého ze standardĤ USB vydávaných USB Implementers Forum (USBIF).
- 20 -
3. Autentizaþní protokoly Autentizaþní protokoly popsané v této þásti jsou oznaþovány jako klasické protokoly. Obvykle jsou používány pro ovČĜení identity, kde uživatel dává doklad o jeho totožnosti. PĜedpokládá se, že tajný klíþ (znalost), který je distribuovaný zabezpeþenou cestou pĜed samotnou autentizací, je známý výluþnČ jeho vlastníkovi. Proto je znalost tajného klíþe považovaná za schopnost prokázat identitu. Na druhou stranu tyto protokoly slouží výluþnČ jen na ovČĜení identity, pĜiþemž skuteþné identifikaþní údaje uživatele jsou témČĜ vždy utajené.
3.1. Protokol Radius Protokol Radius (Remote Authentication Dial In User Service) je protokol pro pĜenos autentizaþních, autorizaþních, konfiguraþních a evidenþních informací mezi pĜístupovým serverem (Radius klient) a spoleþným autentizaþním serverem (Radius server). UmožĖuje centrální správu uživatelských úþtĤ. Radius server autentizuje a autorizuje vzdálené uživatele pro pĜístup do systému. Radius server také rozhoduje o zpĜístupnČní služby (napĜíklad pĜipojení do sítČ). Radius klient je zodpovČdný za odesílání uživatelských informací urþenému Radius serveru a zpracování odpovČdí, které Radius server vrátí. Protokol Radius pracuje na portu UDP 1812. Mezi nejdĤležitČjší rysy patĜí jeho vysoká síĢová bezpeþnost. Transakce mezi klientem a Radius serverem je autentizována pomocí sdíleného tajemství, které není nikdy posíláno pĜes síĢ. Navíc všechna uživatelská jména jsou pĜes síĢ zaslána šifrovaná (šifrování se sdíleným heslem symetrickým algoritmem), a tím je eliminována možnost vysledování nechránČného hesla na síti. Tlumoþníkem mezi uživatelem a Radius serverem je tedy Radius klient (pĜístupový server, fyzický Access Point). Radius server zpracovává požadavek ve 2 krocích - autentizace a autorizace. OvČĜením zkontroluje identitu uživatele, tedy porovná údaje ve své databázi se zaslanými údaji. Po úspČšné autentizaci dojde k autorizaci, která rozhoduje, jaké služby budou uživateli zpĜístupnČny [21].
- 21 -
3.1.1. Funkce protokolu Pokud je klient nakonfigurován k použití Radius protokolu, každý z uživatelĤ musí klientovi pĜedat své autentizaþní údaje. Klient informace od uživatele obdrží jednou a provede autentizaci pomocí Radius protokolu. To udČlá tak, že klient vytvoĜí Access-Request (požadavek o pĜístup), obsahující atributy uživatelské jméno, uživatelské heslo a ID portu, pĜes který je uživatel pĜipojen. Pokud uživatel heslo zadal, je toto heslo ukryto metodou založenou na RSA Message Digest algoritmu MD5. Požadavek Access-Request je odeslán RADIUS serveru pĜes síĢ. Jestliže se nevrátí od Radius serveru žádná odezva v urþeném þase, požadavek je opakovanČ odeslán znovu. Klient mĤže také pĜeposlat požadavek alternativnímu serveru nebo serverĤm v pĜípadČ, že primární server je vypnut nebo nedostupný. Alternativní server mĤže být použit po urþitém poþtu pokusĤ, kdy primární server selhal. Radius server pĜíjme požadavek a ovČĜí odesílajícího klienta. Požadavek od klienta, pro kterého Radius server nemá sdílené tajemství, by mČl být tiše zahozen. Jestliže je totožnost klienta správná, Radius server se podívá do databáze uživatelĤ a vyhledá jméno uživatele, jež je obsaženo v požadavku. Uživatelský záznam v databázi obsahuje seznam parametrĤ (napĜíklad uživatelova IP-adresa nebo IP-adresa Radius klienta, pĜes který se uživatel snaží pĜistupovat) a které musí souhlasit s údaji pro umožnČní pĜístupu uživateli. Pro umožnČní pĜístupu uživateli se ovČĜuje heslo, které mĤže také specifikovat Radius klienta nebo port pĜístupového serveru, pĜes který je uživateli umožnČn pĜístup. Jestliže nČkterá z podmínek není splnČna, Radius server odešle Access-Reject (zamítnutí pĜístupu) zprávu, oznamující, že tento uživatelský požadavek je neplatný. PrĤbČh komunikace mezi uživatelem, klientem a serverem je znázornČn na obrázcích. Na obrázku 6 je pĜípad, kdy nejsou splnČny všechny podmínky nutné pro autentizaci, a tudíž dochází k zamítnutí požadavku [21].
- 22 -
Obrázek ϲ Zamítnutí požadavku [21] Jestliže jsou všechny podmínky splnČny, seznam konfiguraþních hodnot pro uživatele je umístČn do Access-Accept odpovČdi. Tyto hodnoty obsahují typ služby napĜíklad: IP adresu, masku sítČ, login uživatele a všechny hodnoty, které je potĜeba k požadované službČ. Na obrázku 7 je pĜípad, kdy byly splnČny všechny nutné podmínky pro autentizaci a uživateli byl povolen pĜístup k poskytované službČ [21].
Obrázek ϳ Povolení pĜístupu [21]
- 23 -
3.1.2. Formát paketu Data mezi serverem a uživatelem jsou posílána prostĜednictvím Radius paketĤ. Tento paket je zabalen do datové þásti UDP segmentu, kde cílový port je nastaven na hodnotu 1812. PĜi generování odpovČdi požadavku dojde k pĜehození cílového a zdrojového portu. Paket je znázornČn na obrázku 8 [21].
Kód
Identifikátor Délka
Autentizátor Atributy Obrázek ϴ Radius paket Každý paket obsahuje následující informace[21]: • Kód (8 bitĤ)- identifikuje typ radius paketu. V pĜípadČ, kdy je hodnota neplatná, je paket zahozen. MĤže obsahovat hodnoty: o Access-Request - paket je odeslán Radius serveru a zprostĜedkovává informace použité pro rozhodování, zdali má být uživateli umožnČn pĜístup pĜes daný pĜístupový server (Radius klienta). Klient musí Radius paket odeslat s hodnotou 1 v poli Kód. Paket Access-Request musí obsahovat atributy UserName, User-Password. Dále mĤže obsahovat NAS-IP Address, NAS-Port, NAS- Type. o Access-Accept - paket poskytuje specifické konfiguraþní informace potĜebné pro službu, která je poskytována uživateli. o Access-Reject - odesílá se pĜi odmítnutí požadavku. o
Accounting-Request
o Accounting-Response o Access-Challenge • Identifikátor (8 bitù) - pomáhá správnému párování odpovídajících požadavkĤ a odpovČdí. •
Délka (16 bitù) - urþuje velikost paketu. V pĜípadČ, kdy je paket menší, než je urþeno v poli délka, mĤže být paket zahozen. Minimální délka je 20B, maximální délka je 4096B.
• Autentizátor (128 bitù) - jeho hodnota je použita pĜi autentizaci odpovČdi z Radius serveru a dále je použita pĜi šifrování posílaného hesla.
- 24 -
o Request Authentucator (128bitĤ) - náhodnČ velké þíslo, tato hodnota by mČla být nepĜedvídatelná a jedineþná po dobu existence sdíleného hesla mezi serverem a klientem. Radius klient (NAS) a Radius server mají sdílené tajemství. Na toto tajemství je aplikovaná funkce MD5, pomocí které je vytvoĜena 128bitová hodnota, která je xorována s heslem, jež zadal uživatel. o Responce Authenticator - použit v Access-Accept, Access-Reject, AccessChallenge paketech a obsahuje výsledek funkce MD5. • Atributy - nesou specifické autentizaþní, autorizaþní, informaþní a konfiguraþní detaily pro požadavky a odpovČdi. Konec seznamu atributu je urþen délkou Radius paketu. Struktura atributu je znázornČna na obrázku 9. Atributy se skládají z: o Typ (8bitĤ) -obsahuje napĜ. user-name, user-password, chap-password, servicetype a mnoho dalších. o Délka (8 bitĤ) - velikost atributu zahrnující pole typ, délka a hodnota. o Hodnota - má promČnnou velikost. Musí obsahovat jeden z následujících typĤ: string 1- 253 bytĤ adresa 32 bitĤ integer 32 bitĤ time 32 bitĤ Kód (8 bitĤ)
Délka (8 bitĤ)
Hodnota
Obrázek ϵ Struktura atributu
- 25 -
3.2. SchnorrĤv podpis V této kapitole je þerpáno z pramenu [22], kde je tato problematika podrobnČ popsána. SchnorrĤv protokol je založený na obtížnosti úlohy diskrétního logaritmu (místo na obtížnosti úlohy faktorizace). Protokol se znalostí diskrétního logaritmu mĤže být použit uživatelem, aby dokázal znalost diskrétního logaritmu o veĜejné hodnotČ c s ohledem na generátor g a modul p. Uživatel je schopný pĜesvČdþit ovČĜovatele, že zná w=loggc mod p aniž by ho prozradil. To vše za použití diskrétního logaritmu. Tento protokol patĜí mezi protokoly Ȉ, protože splĖuje všechny požadavky. SchnorrĤv protokol pro ovČĜování mezi uživatelem a ovČĜovatelem používá pouze tĜi zprávy. Protokol s dĤkazem znalostí diskrétního logaritmu je znázornČn na obrázku 10. Uživatel zná primární klíþ w, a proto mĤže vypoþítat odpovČć z=(r-ew)mod p pro ovČĜovatele, který je vždy pĜijat ve finálním ovČĜení: c ≡ g z * c e ≡ g r − sw * ( g w ) e ≡ g r * g − ew * g ew ≡ g r ≡ c (mod p )
(2.3)
Znalostní extraktor používá standardní otáþecí techniku. Uživatel se ptá na odpovČć na výzvu e, poté se uživatel vrátí k prvnímu kroku a ptá se na odpovČć na výzvu e´. Nyní má extraktor na dvČ rĤzné výzvy (e, e´) dvČ odpovČdi (z, z´) se stejným prvním krokem. Má tedy dva výstupy, které projdou následujícím ovČĜením:
ܿ Ł ݃( ݁ܿݖmod )
(2.4)
ܿ Ł ݃ݖƍܿ݁ƍ (mod )
(2.5)
Po vydČlení tČchto dvou rovnic a znalostí (e, e´), (z, z´) je extraktor schopný extrahovat primární klíþ w pomocí níže uvedených rovnic:
1 ≡ g z − z´c e−e´ (mod p)
(2.6)
z − z´
1 ≡ g e−e´ c(mod p)
c≡g
w≡
z´− z e´− e
(mod p)
z´− z (mod p ) e − e´
- 26 -
(2.7)
(2.8) (2.9)
Obrázek 10 Schéma Schnorrova protokolu
- 27 -
4. QR kódy QR kód (obrázek 11) je 2D þárový kód, který byl vytvoĜen japonskou spoleþností DensoWave už v roce 1994. QR pochází z anglického Quick Response a vyjadĜuje také to, že zámČrem technologie bylo rozkódovat obsah co nejrychlejším zpĤsobem. QR kód mĤže být využíván bez jakékoliv licence, kód je popsán standardem ISO/EIC 18004. PĤvodnČ byl tento systém vyvinut pro sledování pohybu výrobku v továrnČ, postupnČ ale našel výraznČ širší uplatnČní. Dnes má uplatnČní na mnoha rĤzných místech. Vyskytuje se všude, kde je potĜeba rychle pĜedat vČtší množství informací, které nechceme ruþnČ opisovat tĜeba do mobilu nebo poþítaþe. Místo prostého textu tak staþí uživateli pĜedložit malý (þi velký) þtvercový obrázek. Tyto kódy jsou charakteristické svými soustĜednými þtverci ve tĜech ze þtyĜ rohĤ, které urychlují lokalizování kódu ve scénČ. Kód obsahuje i další prvky, které zkvalitĖují a zrychlují þtení kódu. V dalších kapitolách je uvedeno, z þeho se QR kódy skládají, k þemu slouží jednotlivé prvky, jaké a kolik dat se dá do kódu uložit. Dále jsou také zmínČny generátory a þteþky QR kódu [15].
Obrázek ϭϭ Ukázka QR kódu
- 28 -
4.1. Princip a vlastnosti QR kód existuje ve 40 verzích. Skládá se z bílých a þerných þtvereþních modulĤ. Moduly jsou složeny do þtvercové matice. Zaþíná verzí 1, která obsahuje 21 × 21 bodĤ až po verzi 40, která obsahuje 177 × 177 bodĤ. Každá vyšší verze kódu obsahuje o 4 moduly více na každé stranČ. Jednotlivé verze mají rĤznou kapacitu. Kapacita se mČní s ohledem na použitý typ opravy kódu. V následujících podkapitolách je popsána kapacita, struktura, korekce chyb QR kódu verze 2. 4.1.1. Kapacita BČžné þárové kódy mohou uchovávat maximálnČ 20 þíslic, QR kódy jsou vzhledem ke své velikosti schopny uchovávat velké množství informací (až tisíce znakĤ). QR kód dokáže zakódovat nČkolik typĤ dat jako napĜ. numerické, alfabetické znaky, binární kódy þi japonské znaky kandži. Možná kapacita jednotlivých znakĤ, které lze do kódu uložit, jsou uvedeny na obrázku 12. TYP DAT KAPACITA numerické 7098 znakĤ alfanumerické 4296 znakĤ binární 2953 bytĤ Kandži 1817 znakĤ Obrázek ϭϮ Kapacita QR kódu 4.1.2. Struktura QR kód je složen z þerných a bílých bodĤ, které tvoĜí matici. ýerný modul je logická „1“ a bílý modul je logická „0“. QR kód se skládá z kotvícího obrazce tzv. finder pattern, který je umístČn v levém i pravém horním rohu a spodním levém rohu. Skládá se ze tĜí soustĜedných þtvercĤ a slouží k detekci polohy. Finder pattern je znázornČn na obrázku 13 s pĜesnČ definovanými rozmČry. PomČr šíĜky modulu v každém vzorku zjišĢování polohy je 1:1:3:1:1.
Obrázek ϭϯ Struktura finder pattern
- 29 -
Dalším objektem je Alignment pattern, který slouží k synchronizaci souĜadnic na poĜízeném snímku kódu a souĜadnic matice þerných a bílých bodĤ tohoto kódu v reálném prostĜedí. PĜi poĜízení kódu z nerovného povrchu pomohou tyto souĜadnice pĜi zpracování a narovnání zdeformovaného obrazu. Struktura Alignment patternu je znázornČna na obrázku 14.
Obrázek ϭϰ Struktura Alegnment patern DĤležitým prvkem QR kódu jsou zamČĜovací znaþky tzv.Timing patterns, které urþují hustotu souĜadnicové sítČ QR symbolĤ. Tyto znaþky se skládají z jednoho Ĝádku nebo sloupce stĜídajících se þerných a bílých modulĤ, pĜiþemž vždy se zaþíná a konþí þerným modulem. Separátor slouží k oddČlení referenþních symbolĤ a dat. ŠíĜka separátoru je 1 bod. ýást Quiet zone, neboli prázdný okraj kódu, je tvoĜen oblastí o šíĜce 4 bodĤ kolem celého QR symbolu. UmožĖuje þtecím zaĜízením zamČĜit kód ve scénČ. Zbývající oblast QR kódu je urþena pro vlastní data, korekci chyb a informace o použité masce. Celá struktura kódu je zobrazena a popsána na obrázku 15.
Obrázek ϭϱ Struktura QR kódu
- 30 -
4.1.3. Korekce chyb QR kód má schopnost opravy chyb. U opravy kódu se používá Reed-SolomonĤv algoritmus. Schopnost opravy kódu má 4 úrovnČ. Jednotlivé úrovnČ se liší procentuálním vyjádĜením opravy poškozené matice QR kódu. Jsou to úrovnČ L (7%), M (15%), Q (25%) a H (30%). Z uvedených úrovní je patrné, že maximální poškození matice, kterou je algoritmus schopný opravit, je 30%. Oprava chyb pĜináší také jednu nevýhodu, a tou je, že s rostoucí úrovní opravy chyb klesá kapacita kódu.
4.2. Generátor a þteþka QR kódu QR kódy jsou všude kolem nás, nejprve je ale tĜeba takovýto kód vytvoĜit. K vytváĜení kódu slouží generátor QR kódu. Takový generátor je aplikace, která vytvoĜí QR kód z námi vybraných dat (napĜ. telefonní þíslo, adresa, text). Díky tomu si mĤže každý vytvoĜit svĤj kód, který mĤže libovolnČ používat. NejrozšíĜenČjším Ĝešením jsou online QR generátory volnČ dostupné na spoustČ internetových stránkách, nČkdy rozšíĜené i o vlastní API. Další možností jsou desktopové QR aplikace, nebo aplikace spouštČné z pĜíkazové Ĝádky. Jejich obliba ale zdaleka nedosahuje oblíbenosti webových QR generátorĤ [13,14,15]. K tomu, abychom mohli vygenerovaný QR kód pĜeþíst, potĜebujeme þteþku QR kódu. Ovšem nedostupnost zaĜízení schopných naþíst, dekódovat a udČlat nČco schopného s daty v QR kódu dĜíve bránila QR kódĤm v jejich expanzi. Dnes se jako þteþky QR kódĤ využívají mobilní telefony vybavené digitálním fotoaparátem, které má velké procento lidí. Takováto þteþka je ve své podstatČ software v mobilním telefonu, který skenuje QR kód prostĜednictvím fotoaparátu v mobilním pĜístroji a zajišĢuje, že informace obsažena v kódu bude QR þteþkou rozkódována a zobrazena. Na každou mobilní platformu existuje nČkolik volnČ dostupných aplikací. NapĜ. Kaywa Reader je dostupná jak pro klasické telefony, tak telefony s Androidem þi pro iPhone. Další možností QR þteþky je þteþka fungující jako software v poþítaþi. PĜedstavitelem této aplikace je napĜ. QuickMark [13,14,15].
- 31 -
5. Operaþní systém Android Android je operaþní systém, který vznikl pĜedevším pro mobilní zaĜízení, ale ne jen pro nČj. Je urþen také pro tablety, navigace, PDA, þteþky elektronických knih, netbooky, MP4 pĜehrávaþe a chytré televize. Operaþní systém je postavený na linuxovém jádru. Jedná se o software s otevĜeným zdrojovým kódem (open source ptlatform) což umožĖuje systém využívat zdarma, pĜetváĜet jej a pĜi splnČní podmínek distribuovat [23].
5.1. Historie Spoleþnost Android Inc. byla založena v Ĝíjnu 2003 v Kalifornii. Google Inc. v srpnu roku 2005 odkoupil firmu Android Inc. a udČlal z ní svoji dceĜinou spoleþnost. Po odkupu spoleþnosti tým Googlu vyvinul platformu založenou na Linuxovém jádĜe a v záĜí roku 2007 Google získal nČkolik patentĤ v oblasti mobilních technologií. V tomtéž roce bylo vytvoĜeno uskupení Open Handset Alliance (OHA). OHA zahrnuje nČkolik spoleþností zabývajících se výrobou mobilních telefonĤ, þipĤ nebo mobilních aplikací. Mezi tyto spoleþnosti patĜí Google, HTC, Intel, LG, Motorola, NVIDIA, Samsung a dalších 27 spoleþností. Cílem OHA bylo vyvinout otevĜený standard pro mobilní zaĜízení. První verze operaþního systému Android vyšla v roce 2007. V Ĝíjnu 2008 byl uveden první komerþní telefon HTC Dream s operaþním systémem Android. V dalších letech poté vycházely nové verze OS. Koncem roku 2010 se Android stal vedoucí platformou smartphonĤ [23,24].
5.2. Architektura V této kapitole je þerpáno ze zdrojĤ [23,25]. Architektura Androidu se dá rozdČlit celkem do pČti vrstev: jádro, knihovny, aplikaþní framework, bČhové prostĜedí a aplikace. Každá vrstva má svĤj úþel a nemusí být pĜímo oddČlena od ostatních vrstev. Obrázek 16 ukazuje architekturu OS Android. Nejnižší vrstvou architektury je jádro operaþního systému, které tvoĜí abstraktní vrstvu mezi používaným hardwarem a zbytkem softwaru o ostatních vrstvách.
Jádro mobilního
operaþního systému Androidu je postaveno na Linuxu ve verzi 2.6. Využívá celé Ĝady jeho vlastností, napĜ. podpory správy pamČti, správy sítí, zabudované ovladaþe nebo správy procesĤ.
- 32 -
Druhou vrstvou jsou knihovny. Ty jsou napsány v jazyce C nebo C++ a obsahují kód, který poskytuje hlavní funkce na OS Android. Mezi pĜíklady knihoven patĜí SQLite, která nabízí databázovou podporu a WebKit, který poskytuje funkce pro prohlížení webových stránek. Vrstva Android Runtime obsahuje aplikaþní virtuální stroj oznaþovaný jako Dalvik. Dalvik Virtual Machine (DVM) je registrovČ orientovaná architektura, využívá základních vlastností linuxového jádra. DĤvodem pro vznik DVM byla licenþní práva, kdy jazyk Java a jeho knihovny jsou volnČ šiĜitelné, kdežto JVM nikoliv. Dalším dĤvodem byla optimalizace virtuálního stroje pro mobilní zaĜízení a to pĜedevším v oblasti pomČru úspory energie a výkonu. PĜeklad aplikace napsané pro Android probíhá zkompilováním zdrojového kódu v jazyce Java do Java byte kódu. Poté se pĜekompiluje Java byte kód pomocí DVM a výsledný Dalvik byte kód je spuštČn na DVM. Každá spuštČná Android aplikace bČží ve svém vlastním procesu s vlastní instancí DVM. ýtvrtou vrstvou je Aplikaþní vrstva (Application framework) je pro vývojáĜe nejdĤležitČjší. Poskytuje pĜístup k velkému poþtu služeb, které mohou být použity pĜímo v aplikacích. Poslední vrstvou jsou aplikace, které využívají bČžní uživatelé. MĤže jít o aplikace pĜedinstalované, nebo dodateþnČ stažené z Android Marketu. NapĜíklad e-mailový klient, kalendáĜ, mapy, atd.
Obrázek 16 Architektura OS
- 33 -
6. Vývojové prostĜedí Eclipse Jako vývojové prostĜedí je využit editor Eclipse dostupný z webové stránky www.eclipse.org, který pĜímo spolupracuje se spoleþností vyvíjející OS Android. Po instalaci vývojového prostĜedí Eclipse je nutné nainstalovat balíþek ADT (Android Development Tool) a balíþek SDK (Software Development Kit). Instalace následujících balíþku bude popsána v následující podkapitole. Uživatelské prostĜedí programu Eclipse je zobrazeno na obrázku 17. PĜi zakládání nového projektu je nutné dodržet adresáĜovou strukturu[23]: • AndroidManifest.xml - soubor popisující celou aplikaci, její aktivity, služby, intenty • src - zdrojový kód aplikace • res - soubory zdrojĤ napĜ. obrázkĤ, layouty, ikony • assets - pĜídavné soubory • bin - pĜeložené binární soustavy • gen - automaticky generované zdrojové kódy Nový projekt vytvoĜíme pomocí File -> New -> Android Application Project a tím zajistíme správné dodržení adresáĜové struktury celého projektu.
Obrázek 17 Uživatelské prostĜedí programu Eclipse
- 34 -
6.1. Instalace ADT ADT (Android Development Tool) poskytuje výkonné prostĜedí, ve kterém lze vytváĜet Android aplikace. Instalaci ADT v programu Eclipse provedeme kliknutím na záložku Help > Install New Software. V následujícím dialogovém oknČ, viz. obrázek 18, klikneme na možnost Add a zobrazí se Add Repository. Do položky Name zadáme název pluginu. Do položky Location zadáme webovou adresu https://dl-ssl.google.com/android/eclipse/, odkud se plugin stáhne.
Obrázek 18 Instalace ADT Poté v dialogovém oknu zaškrtneme všechny možné výbČry a pokraþujeme v instalaþním prĤvodci. Po instalaci ADT pluginu je nutné správnČ nakonfigurovat SDK. To provedeme kliknutím na záložku Windows -> Preferences -> Android. Zde do pole SDK location zadáme adresu, kde se v poþítaþi SDK nachází. Dialogové okno je zobrazeno na obrázku 19 [23].
- 35 -
Obrázek 19 Instalace SDK
6.2. Instalace SDK Plugin SDK ( Software Development Kit) slouží pro vytvoĜení aplikace pro rĤzné OS. Tímto balíþkem Eclipse získa pĜístup ke knihovnám API a JAVA. Souþástí SDK je také emulátor umožĖující simulovat rĤzné konfigurace prostĜedí, mezi které patĜí napĜíklad rozlišení obrazovky, velikost operaþní pamČti, velikost interní pamČti þi SD karty. Emulátor je schopen vyvolávat akce, které vznikají pĜi bČhu programu, jako je napĜíklad pĜíchod hovoru. Za pomoci tohoto emulátoru je možné vyvíjet kompletní aplikace bez nutnosti vlastnit fyzické zaĜízení obsahující OS Android. V pĜípadČ dostupnosti fyzického zaĜízení je možné ladit aplikaci pĜímo na zaĜízení pĜes USB kabel. SDK je možné stáhnout pĜímo z webových stránek http://developer.android.com/sdk/index.html. Po instalaci SDK pluginu se nám otevĜe SDK manager, kde je zobrazen výbČr dostupných platforem. Zaškrtnutím provedeme instalaci vybraných doplĖkĤ [23,26].
6.3. AVD Manager Pro ovČĜení funkþnosti urþité þásti kódu, nebo celé aplikace, slouží ladící (debug) režim. SpouštČní ladícího režimu se provede pomocí Run -> Debug Configurations, kde se v záložce Target nastaví, na kterém z virtuálních zaĜízení bude aplikace spuštČna (obrázek 20).
- 36 -
Obrázek 20 Ladící režim VytvoĜení virtuálních zaĜízení se provádí v AVD Manageru, který je souþástí Android SDK (obrázek 21).
Obrázek Ϯϭ AVD Manager Zde je taky možné vybrat, zda se bude provádČt ladČní na fyzickém zaĜízení pĜipojeném pĜes USB, nebo na emulátoru. Aplikace se po spuštČní ladícího režimu automaticky nainstaluje a spojí s programem. Pokud aplikaci ladíme na fyzickém zaĜízení, je nutné provést instalaci ovladaþĤ USB zaĜízení, které jsou souþástí Android SDK, a zapnout podporu ladČní na konkrétním fyzickém zaĜízení [23].
- 37 -
7. Implementace kryptografického protokolu Praktická þást diplomové práce je zamČĜena na využití chytrých telefonĤ v oblasti bezpeþné autentizace a autorizace uživatelĤ. PĜedevším na možnost implementace kryptografických protokolĤ na platformČ Android s využitím QR kódu pro pĜenos dat. Implementovaný kryptografický protokol je vyvíjen na fakultČ FEKT VUT v BrnČ. Vyvíjené schéma se nazývá „Unlinkable Attribute-Based Credentials with Practical Revocation on Smart-Cards“. Autentizaþní schéma umožĖuje revokaci odvolaných uživatelĤ a deanonymizaci útoþníkĤ. Tato kapitola je popsána z pramenu [27].
7.1. O schématu Atributové povČĜení bylo navrženo k zlepšení ochrany soukromí uživatele. PĜi použití atributového povČĜení mĤže uživatel anonymnČ prokázat nČkterý z atributĤ. Atributy jsou prezentovány osobními údaji uživatele (napĜ. vČk, Ĝidiþský prĤkaz). Na rozdíl od klasického ovČĜení není identita uživatele nikdy vydána. To znamená, že ovČĜovací proces je anonymní a tím se zvČtšuje ochrana soukromí uživatele. PĜi použití atributového povČĜení založeného na QR kódech by uživatelé mohli prokázat svoje atributy, aniž by prozradili svoji totožnost, pĜípadnČ jiné soukromé informace, které by mohl ovČĜovatel zneužít. S rostoucím poþtem elektronických služeb, je nutné zvýšit ochranu soukromí uživatele. ZvlášĢ obtížná je revokace a identifikace podvádČjícího uživatele pomocí stávajících systémĤ, proto byl vytvoĜen nový systém, který tyto funkce umožĖuje. Atributové povČĜení by tedy mČlo být schopno poskytnout následující funkce[27]: • anonymita: identita uživatele by mČla zĤstat pĜi ovČĜování ovČĜovatelem stále skryta • nesledovatelnost: vydavatel není schopen dohledat vydané atributy a jejich vlastníky • nespojitelnost: ovČĜení relace jednoho uživatele jsou vzájemnČ nespojitelné • selektivní zveĜejnČní atributĤ: uživatel mĤže zpĜístupnit ovČĜovateli pouze urþité soukromé atributy pro ovČĜení • nepĜenosnost: zabránČno pĤjþování povČĜení • revokace: zrušení platnosti ztracené, odcizené karty
- 38 -
• identifikace neþestného a podvádČjícího uživatele: odhalení neþestného a podvádČjící uživatele i pĜesto, že prokázání atributĤ je anonymní.
7.2. Souþasný stav revokaþních technik Pro zajištČní soukromí uživatele pĜi ovČĜení relace by mČl uživatel zĤstat zcela anonymní a nemČlo by docházet k odhalení jeho osobních informací, které by mohly být pozdČji dohledány. Ovšem v pĜípadČ, kdy je mobilní telefon uživatele odcizen þi ztracen je nutné po ovČĜení uživatele jej zrušit, aby nedocházelo v budoucnosti k jeho zneužití. ZároveĖ ale musí existovat i zpĤsob, kdy pĜi porušení urþitých pravidel spoleþnosti bude identita uživatele odhalena. Souþasné revokaþní techniky toto neumožĖují. Více informací lze nalézt v [27]. Proto byl vytvoĜen nový autentizaþní protokol nespojitelného atributového povČĜení s praktickou revokací. Tento protokol má následující vylepšení: • Okamžité zrušení platnosti povČĜení, což znamená, že nemusí þekat na vypršení urþité doby platnosti. • Revokace je dostupná jak pro vydavatele, tak pro ovČĜovatele. Oba dva tedy mohou zahájit revokaci uživatele. • Platný uživatel nemĤže pĜevzít nebo stáhnout hodnoty od zrušeného uživatele. • OvČĜovací relace bČží pouze mezi uživatelem a ovČĜovatelem a není potĜeba komunikovat s jinou stranou. Revokace ovČĜení je velmi dĤležitý prvek, ale v nČkterých pĜípadech nestaþí pouze odstranit uživatele ze systému, ale v pĜípadČ vzniku škody potĜebuje poskytovatel služeb urþitou techniku, která mu umožní, aby se útoþník zodpovídal za zpĤsobené škody. Proto schéma umožĖuje i zrušení urþitých funkcí, jako je nespojitelnost a anonymita. Pokud je potĜeba zkontrolovat minulost uživatele, využije se funkce zrušení nespojitelnosti. Jakmile ale uživatel porušil závažné pravidla, je možné zrušit jeho anonymitu, aby byl zodpovČdný za své þiny. Vzhledem k tČmto skuteþnostem je nutné revokaþní techniku silnČ chránit pĜed zneužitím. Proto se schopnost revokovat rozšíĜila na více entit. V tomto systému musí spolupracovat ovČĜovatel, vydavatel a revokaþní rozhodþí na revokaci soukromých údajĤ uživatele. Tímto zpĤsobem se omezí možné zneužití jedním ze subjektĤ (V + RR). KromČ toho má uživatel svobodnou volbu, kdy si mĤže zvolit atribut od vydavatele, kterému nejvíce dĤvČĜuje [27].
- 39 -
7.3. Schéma atributového ovČĜení V této þásti je popsáno nové schéma pro povČĜení na bázi atributĤ. Jsou zde popsány subjekty, všeobecný vzor komunikace a základní kryptografické funkce. V navrhovaném schématu jsou k dispozici þtyĜi subjekty. NČkteré z nich mají v držení tajné klíþe, jak je vidČt na obrázku 22. Mezi subjekty patĜí: • Vydavatel – V: subjekt, který vydává osobní atributy pro uživatele. Vydavatel, revokaþní rozhodþí a ovČĜovatel spolupracují pĜi zrušení anonymity a odhalení uživatele se zlými úmysly. Vydavatel vlastní klíþ ܸܭ. • Revokaþní rozhodþí – RR: subjekt, který generuje systémové parametry params, spolupracuje s vydavatelem pĜi vydávání atributĤ uživatele, a jak již bylo popsáno, spolupracuje i pĜi zrušení anonymity s vydavatelem a ovČĜovatelem. Revokaþní rozhodþí funguje jako záruka ochrany osobních údajĤ, protože rozhoduje o typu revokace (revokace povČĜení, revokace nespojitelnosti nebo revokace anonymity) na základČ dĤkazĤ poskytnutých ovČĜovatelem. Revokaþní rozhodþí není sám schopný revokovat nebo odhalit soukromé informace uživatele, ale pro zvýšení bezpeþnosti pouze ve spolupráci s ovČĜovatelem a vydavatelem. Revokaþní rozhodþí vlastní klíþ ܴܴܭ. • Uživatel – U: subjekt, který je majitelem QR kódu s vydanými atributy. Uživatel mĤže anonymnČ prokázat vlastnictví atributĤ pomocí tohoto QR kódu. Každý QR kód má tajný jedineþný klíþ ܷܭ, urþený pro generování dĤkazních atributĤ. Navíc uživatel generuje i tajný klíþ ܵܭpro ovČĜení, které je zároveĖ zcela náhodné, aby bylo nespojitelné s pĜecházející operací. • OvČĜovatel – O: subjekt, který ovČĜuje vlastnictví uživatelských atributĤ. Používá databázi k ovČĜení relace a evidence porušených pravidel. OvČĜovatel mĤže požádat revokaþního rozhodþího o revokaci uživatele. Pokud revokaþní rozhodþí rozhodne, že je revokace správná, uživatelský klíþ ܷܭbude revokován a tím mĤže dojít i k zveĜejnČní identity podvádČjícího uživatele.
- 40 -
Obrázek 22 Schéma atributového ovČĜení Atributové povČĜení se skládá ze þtyĜ fází. V diplomové práci je popsána pouze jedna fáze atributového povČĜení. Popsanou fází je protokol bČžící mezi uživatelem a ovČĜovatelem. Je to z dĤvodu, že praktická þást diplomové práce byla zamČĜena na tento protokol mezi uživatelem a ovČĜovatelem.
݂ݎĸ dokazovací protokol (ݏ݉ܽݎܽ,)ܷܭ: tento protokol bČží mezi uživatelem a ovČĜovatelem, jak je i znázornČno na obrázku 22. Uživatel získá z pĜedcházející fáze na svĤj QR kód atribut, což je vlastnost uživatele. Tuto vlastnost uživateli vydává revokaþní rozhodþí a vydavatel. Na Obr. 23 je znázornČn celý autentizaþní protokol. Uživatel má uložené tajné klíþe ݓ1,ݓ2 a ܴܴݓ, kterými se následnČ prokazuje ovČĜovateli. Prokazuje to ale takovým zpĤsobem, že celou operaci mĤže provést vícekrát za sebou. OvČĜovatel tak nebude schopný vČdČt, zda se jedná stále o stejného uživatele nebo již jiného. To je zpĤsobeno využitím þísel
ܵܭ, ݎ1, ݎ2, ݎ3 a ܵݎ, které jsou náhodnČ generovány. Každá relace bude zcela náhodná a nespojitelná a nesmí se nikdy objevit dvČ stejná þísla. Toto lze zkontrolovat v praktické þásti, napĜ. pozorováním þísel ݖ1, ݖ2, ݖ3 a ܵݖ, které jsou stále náhodné. Proto, když se uživatel prokazuje ovČĜovateli v rĤzných þasových okamžicích, nebude ovČĜovatel schopný pĜesnČ urþit, zda se jedná o stejného uživatele nebo již jiného. Jediné, co ale ovČĜovatel ví, že žádost pochází od uživatele, který zná tajné klíþe ݓ1, ݓ2 a [ ܴܴݓ27].
- 41 -
7.4. Implementace autentizaþního schématu VytvoĜený program pĜedstavuje implementaci komunikace mezi uživatelem (client) a ovČĜovatelem (verifier) tedy popis þásti ݂ݎĸ dokazovací protokol (ݏ݉ܽݎܽ,)ܷܭ. V aplikaci Client se na základČ implementovaného protokolu vygeneruje QR kód. U aplikace Verifier po naþtení vygenerovaného QR kódu ze strany Client doje k jeho ovČĜení na základČ implementovaného protokolu. Autentizaþní protokol je znázornČn na obrázku 23 [27].
$VHHGQ YHONiSUYRþtVOD JJJ JHQHUiWRUQiKRGQêFKþtVHO
8åLYDWHO
2YČĜRYDWHO
ZZZUU .V ȃ Ƈɥřɨƈɮɰ $ $VHHG.V PRGQ & J.V ZUUPRGQ & J.VPRGQ Uȃ ^` Uȃ ^` Uȃ ^` UVȃ ^` $ଲVHHG JUJUJU PRGQ $ଲ $VHHGUV PRGQ &ଲ JUPRGQ &ଲ JUVPRGQ H dz$$ଲ$VHHG$ଲVHHG&&&ଲ&ଲ W = = = =V
UH.VZ UH.VZ UH.VZUU UVH.V
$&&H]]]]V $ଲVHHG $HJ]J]J] PRGQ $ଲ $H$VHHG]V PRGQ &ଲ &HJ]PRGQ &ଲ &HJ]PRGQ H dz$$ଲ$VHHG$ଲVHHG&&&ଲ&ଲ W
Obrázek 23 Autentizaþní protokol PromČnné, které má uživatel zadané jsou Aseed, g1, g2, g3, n, w1, w2, wrr. Pro aplikace vytvoĜené v rámci diplomové práce jsou hodnoty tČchto promČnných následující: Aseed=“163295020074095216338389889392355010013938953620055323241425090524051 149359194354000604257804921174408772252439162081187699483815388733331404406 681951694324014279113937586477809306994171461466217443757704366992310952986
- 42 -
530069173556223156000205202227562426484389932045623849393361372299072847514 32455999508686“ g1=“15636006389460839935516688281297992612886913774888125758150982595388466 13056773792391112492223839595838453“ g2=“60495711636149203090530020668747070886342806525470808135893906991586024 089645503374332334817097561809958693329779638336584563011952539081983410297 528144138780662796997073720806611853629699471027183576963308926838170660943 573614810461335164939746741583200785053679616166464662000163035214910577722 502082334627“ g3=“72326884785606683175386580803890669194818591203457682587127986987277924 235727374782792160767389828595176010348356839530301237407471274470735225818 081137885231605471785562795609310821299811528837078199170816555134715618378 872951824044011067055769783264982077170685482442109901611348413864656329864 41971483661“ n=“627738883869207299094419551502253900567344184355220076333324604905615296 309614614278202198800086410813218648076728633303540260550781847355902114517 112371193780445775880762722843239695904094053881540065367798744737134884192 745858620653275690109287258459851450691674791914619052867549343670499223317 07598335811“ w1=“ 884724555167536571067677515255024303599289666490“ w2=“936272962676640508757334“ wrr=“10092520358172748202917539956397476634051598920172957446786888015856056 71701743694427200901227903“ Podrobný popis aplikací Client a Verifier je v dalších kapitolách.
7.4.1. Aplikace Client V této podkapitole je popsána mobilní þást aplikace, tedy Client. V této aplikaci je implementováno autentizaþní schéma. Po výpoþtu jednotlivých promČnných se následnČ vygeneruje QR kód, který se zobrazí na displeji mobilního zaĜízení. V aplikaci Client jsou deklarovány tĜídy Contents, GenQRCode a QRCodeEncoder.
- 43 -
V tČchto tĜídách jsou deklarovány všechny komponenty, promČnné, metody a funkce, které jsou souþástí aplikace. Pro generování QR kódu je použita knihovna Zxing, která je volnČ ke stažení na webových stránkách https://code.google.com/p/zxing/. Samotný autentizaþní protokol je definovaný ve tĜídČ Protocol a ExchangeData. PromČnné ݀݁݁ݏܣ, 1, 2, 3 a n jsou definovány jako datový typ BigInteger. PĜi výpoþtu samotného autentizaþního protokolu jsou využívány kombinace jednotlivých operací. PĜi výpoþtu parametru Aࡘ seed=g1r1 g2r2 g3r3mod n je spoþítán kombinací modulárního umocĖování a modulárního násobení. Výpoþet parametru Aࡘ seed=g1r1 g2r2 g3r3mod n: ɏɏʰɏɨŜſɏɨřƀŜſɏɩŜſɏɩřƀƀŜſɏɪŜ ſɏɪřƀƀŜſƀŚ
Výpoþet parametru Aࡘ =Aseedrs mod n: ɏʰɏŜſɏřƀŚ
Výpoþet parametru Cࡘ 1 =g3r3 mod n: ɏɨɏʰɏɪŜſɏɪřƀŚ
Výpoþet parametru Cࡘ 2 =g3rs mod n: ɏɩɏʰɏɪŜſɏřƀŚ
Deklarace parametru KSȯR{0,1}79:
ɕɕʰɮɰŚ ɏʰ ſɕɕřƀŚ
StejnČ jak je definován parametr KS jsou definovány také parametry r1, r2, r3 a rs . Výpoþet parametru A =AseedKs mod n: ʰɏŜſɏřƀŚ
Výpoþet parametru C1 =g3Kswrr mod n: ɏɨʰɏɪŜſɏŜſɏƀřƀŚ
Výpoþet parametru C2 =g3Ks mod n: ɏɩʰɏɪŜſɏřƀŚ
Dalším pĜíkladem využití kombinací jednotlivých operací pĜi výpoþtu parametrĤ jsou parametry z1, z2, z3, zs, které jsou kombinací modulárního násobení a rozdílu velkých þísel.
- 44 -
Výpoþet parametru z1=r1-eKsw1: ɏɨʰɏɨŜ
ſŜſɏƀŜſɏɨƀƀŚ
Jedním z posledních parametrĤ pro výpoþet je promČnná e=dz(A, Aࡘ , Aseed, Aࡘ seed, C1, C2, Cࡘ 1, Cࡘ 2, t), což je hash jednotlivých parametrĤ. Jednotlivé promČnnČ jsou deklarovány jako pole byte a výsledný hash je hashem jednotlivých polí byte. Hashovací funkce byla zvolená SHA-1 s výstupem dlouhých 160bitĤ. Celý zdrojový kód je v pĜíloze diplomové práce. Výpoþet parametru e=dz(A ,Aࡘ ,Aseed ,Aࡘ seed ,C1 ,C2 , Cࡘ 1, Cࡘ 2, t): ƃƄɏʰ
ſƃƄƃƄƇɏřɏɏřɏɏř ɏɏɏřɏɏɨřɏɏɩřɏɏɨɏřɏɏɩɏřɏƈƀŚ Ś Ƈ ʰŜ
ſɑŞɨɑƀŚ ƈ
ſ
ƀƇ
ſƀŚ ƈ ŜſƀŚ ƃƄɏʰŜſɏƀŚ ʰ ſʫɨřɏƀŚ
Pro kontrolu, jestli výpoþet implementovaného autentizaþního schématu je správný je vytvoĜena tĜída ProtocolTest. V této tĜídČ je provedeno kódování výstupu a ovČĜování výstupu. Po spuštČní testu se v konzolovém oknČ zobrazí zadané, vypoþtené a vymČnČné data na kódovaném výstupu. Na stranČ ovČĜování výstupu jsou zobrazeny také zadané, vymČnČné a vypoþtené data. Aby test probČhl v poĜádku, musí se výpoþty jednotlivých parametrĤ ݀݁݁ݏܣ, ܣ,
ܥ1, ܥ2, ݁, ݖ1, ݖ2, ݖ3 a ݏݖshodovat. Ukázka þásti testu je na obrázku 24, kde je vidČt výpis konzolového okna. Celková doba trvání testu byla 346ms. Celkový test a jejich hodnoty budou uvedeny v pĜíloze.
- 45 -
Obrázek 24 Test - ovČĜení protokolu Po zapnutí aplikace na mobilním zaĜízení jak je vidČt na obrázku 25, se na úvodní obrazovce zobrazí vygenerovaný QR kód. Pod ním se nachází aktuální datum a þas, kdy byl daný kód vygenerován. Vedle aktuálního þasu je zobrazena þíselná hodnota promČnné e. Aplikace byla testovaná jak na virtuálním zaĜízení ve vývojovém prostĜedí Eclipse, tak na mobilním zaĜízení Samsung GT-i9000 a HTC Desire.
Obrázek 25 Aplikace Client - 46 -
7.4.2. Aplikace Verifier V této podkapitole je popsána serverová þást aplikace, tedy ovČĜovatel (verifier). V této aplikaci je implementována þteþka QR kódu, která má za úkol naskenovat pĜiložený QR kód. Dále je implementováno autentizací schéma na stranČ ovČĜovatele, které je zobrazeno na obrázku 23. Na základČ pĜijatých dat od klienta se vypoþítají potĜebné parametry, a pokud se hodnoty shodují, je ovČĜení v poĜádku. V aplikaci Verifier jsou deklarovány tĜídy IntentIntegrator, IntentResult, ve kterých jsou deklarována þteþka QR kódu a výsledky skenování. V tĜídČ IntentResult jsou metody, které obsahují obsah QR kódĤ, formát a otáþení obrazu. TĜída IntentIntegrator obsahuje metody pro þtení QR kódĤ. K její funkþnosti je potĜeba pĜipojit Android knihovnu v našem pĜípadČ s názvem Reader. Tím se volá integrovaný skener þárových kódĤ. Dále je definována tĜída MainActivity, ve které je popsána þinnost, která pĤsobí jako ovČĜovatel. TĜída MainAcitivity obsahuje metodu pro zahájení skenování startScan:
ſƀƇ Ŝ
ſ ŜɕɕƀŚ ƈ ŵŵ ɒ
ſřř ƀƇ Ŝ
ſřřƀŚ ʰ Ŝ
ſřřƀŚ Ŝ
ſɥɥɥɥɥɥɥɥɥƀŚ ŜſɑŜŜŜɑƀŚ ŜſŜ ƀŚ ſſƀƇ ɒ
ſƀƇ
ſƀŚ ƈ ƈƀŜſƀŚ ƈ
Další metoda ProcessResult se stará o zpracování naskenovaného výsledku. Po naþtení metody se vytvoĜí konfigurace, které jsou obsaženy v IntentResult.
ſ ƀƇ ʰŜ
ſƀŚ ʰŚ ſŠʰƀƇ ʰŜſƀŚ ſŠʰƀƇ
ʰ
Ŝ ſƀŚ ſŠʰƀƇ
- 47 -
ʰ
Ŝſřŵɨɥɥɥř
řƀŚ ƈ ƈ ƈ ʰ ŜſɑŞŞśśɑř ŜŜſƀƀŜſƀʫɑŚɑʫŵɨɥɥɥŚ ʰŚ ŜſſƀƇ ɒ
ſƀƇ ŜſƀŚ ſŠʰĺĺƀƇ ŜſɑɑƀŚ Ŝ
ſɥ ɥɥ ɥɥƀŚ ƈƇ Ŝſɑ ɑƀŚ Ŝ
ſɥ ɥɥɥɥƀŚ ƈ ŜſŜ ƀŚ ŜſŜ ƀŚ ſƀŚ
Následující metoda je volána pĜi dokonþení ovČĜení a zajišĢuje, že výsledek validace se zobrazí pouze na krátkou dobu, a poté se opČt spustí další skenování. ſƀƇ ŜſſƀƇ ɒ
ſƀƇ ŜſŜ ƀŚ ŜſŜ ƀŚ ſĺĺŜ
ſƀƀƇ
ſƀŚ ƈ ƈ ƈřɬɥɥɥƀŚ ƈ ɒ
ſ
ƀƇ Ŝſ
ƀŚ ſŜŜ
ɕƀŚ ʰ ſƀŚ ʰſƀ ſŜŜƀŚ ʰſƀ ſŜŜƀŚ ʰſ
ƀ ſŜŜƀŚ ʰſƀŚ ſ
ŠʰƀƇ
ʰ
ŜſɕƀŚ ƈƇ
ſƀŚ ƈ ʰŚ
- 48 -
Zde jsou pouze ukázky kódu, který daná aplikace obsahuje. Kompletní kódy jsou pĜiloženy v pĜíloze diplomové práce. Po zapnutí se aplikace zobrazí na displeji vertikálnČ. Úvodní obrazovka vyzve uživatele pro zadání þasové tolerance pro naþtení QR kódu jak je znázornČno na obrázku 26. ýasová tolerance je zadávaná v sekundách. Pro správnou funkþnost se doporuþuje þasová tolerance alespoĖ 60 sekund. ýasová tolerance je z dĤvodu, že ovČĜovatel nestihne ovČĜit QR kód ve stejný þas, ve kterém byl vygenerován.
Obrázek 26 Aplikace Verifier - þasová tolerance Na obrázku 27 je zobrazena aplikace pĜed zahájením skenování QR kódu. V dolní þásti je umístČno tlaþítko RUN pro zahájení skenování. Nad ním je checkbox, jehož zaškrtnutím zajistíme nepĜetržitý provoz skenování. Nebudeme muset po každém naskenování opČt pouštČt pomocí tlaþítka RUN.
Obrázek 27 Aplikace Verifier - základní obrazovka
- 49 -
Po stisknutí tlaþítka RUN je k dispozici skener, pomocí kterého naþteme QR kód, který nám vygenerovala aplikace Client. Ukázka je na obrázku 28.
Obrázek 28 Aplikace Verifier - skenování QR kódu Po naþtení kódu jsou k dispozici tĜi možné varianty: • QR kód byl naþten v þasové toleranci a ovČĜení probČhlo v poĜádku. Aplikace
napíše hlášení „OK“. Pod vyjádĜením jestli QR kód byl ovČĜen þi nikoliv je zobrazen aktuální datum a þas a hodnota promČnné e. Ukázka aplikace je na obrázku 29.
Obrázek 29 Aplikace Verifier - správné ovČĜení
- 50 -
• QR kód byl naþten v þasové toleranci a ovČĜení neprobČhlo v poĜádku.
Aplikace napíše hlášení „INVALID“. • QR kód nebyl naþten v þasové toleranci a tudíž opČt ovČĜení neprobČhlo.
Aplikace napíše hlášení „INVALID“ jenž mĤžeme vidČt na obrázku 30.
Obrázek 30 Aplikace Verifier - chybné ovČĜení
- 51 -
ZávČr V teoretické þásti diplomové práce bylo cílem seznámit se oblastí bezpeþné autentizace a autorizace uživatelĤ za použití chytrých telefonĤ. V první kapitole je popsána problematika kryptografie, kde je vysvČtlena modulární aritmetika, symetrická a asymetrická kryptografie. Dále je popsán princip digitálního podpisu a zmínka o hashovací funkci. Modulární aritmetika spolu s hashovací funkcí je využita v praktické þásti diplomové práce. Druhá kapitola je zamČĜena na popis autentizace. V této kapitole je vysvČtleno, co to autentizace je a jaké druhy existují. Autentizaci dČlíme na autentizaci znalostí, žadatelem a pĜedmČtem. TĜetí kapitola je vČnována autentizaþním mechanismĤm, a to konkrétnČ Radius protokolu a Schnorrovu protokolu. ýtvrtá kapitola je vČnována QR kódĤm. KonkrétnČ zde popisuji vlastnosti a princip QR kódu. Je zde také zmínka o generátorech a þteþkách QR kódu. Pátou kapitolu tvoĜí popis operaþního systému Android, který je pĜevážnČ urþen pro mobilní telefony. Je zde popsána jeho historie a architektura. V praktické þásti bylo úkolem seznámit se s vývojovým prostĜedím Eclipse a Android SDK, které slouží k vývoji aplikací pro mobilní telefony bČžící na platformČ Android. Dále vytvoĜit aplikaci, která bude v sobČ mít implementované autentizaþní schéma s využitím QR kódu. Konkrétní autentizaþní schéma je vyvíjeno na FEKT VUT v BrnČ, a to jak pro klientskou, tak serverovou þást. VytvoĜené aplikace využívají nČkteré z matematických funkcí, jako jsou generování velkých þísel, modulární násobení, modulární umocnČní a hash funkce. VytvoĜená aplikace pro klientskou þást se nazývá Client a generuje QR kód. V QR kódu jsou obsaženy data, které jsou vypoþteny pomocí zadaného autentizaþního schématu. Funkþnost aplikace byla testována na mobilním zaĜízení. Druhá vytvoĜená aplikace pro serverovou þást se nazývá Verifier neboli ovČĜovatel. Tato aplikace dokáže ovČĜit QR kód, který vygenerovala aplikace Client v klientské þásti. Tato aplikace po spuštČní a zadaní þasové tolerance pro naþtení kódu dokáže naskenovat daný QR kód a pomocí výpoþtu, které jsou implementovány v autentizaþním schématu urþit, zda se data shoduji s daty, které vygenerovala klientská þást þi nikoli. Po ovČĜení napíše aplikace hlášení, zda daný QR kód byl ovČĜen, nebo ne. Pro správnou funkþnost obou aplikací je nutné mít na mobilních zaĜízeních synchronizován aktuální datum a þas. Pomocí této aplikace je umožnČn bezpeþný pĜenos dat pomocí QR kódu mezi uživatelem a serverem.
- 52 -
Seznam použité literatury [1] OCHODKOVÁ, Eliška. Matematické základy kryptografických algoritmĤ. [online]. 2011, s.89[cit. 2014-04-24].Dostupné z: http://mi21.vsb.cz/sites/mi21.vsb.cz/files/unit/mat_zaklady_kryptografickych_algoritmu.pdf [2] STALLINGS, W. Cryptography and network security. Vyd. 1. New Jersey: Prentice-Hall, 1999, 569 s. ISBN 01-386-9017-0 [cit. 2014-04-24] [3] MARŠÍK, ZdenČk. ZM-Soft digitalní podpis. [online]. 2011 [cit. 2014-04-24]. Dostupné z: http://zmsoft.cz/index.php?str=sifrovani_a_dig._podpis&hid=3&idmh=3 [4] RFC 4880 OpenPGP Message Format. [online]. 2007, s. 88 [cit. 2014-04-24]. Dostupné z: http://tools.ietf.org/html/rfc4880#section-2.2 [5]
BċHÁLEK M. Pravdy Bezpeþnost a zabezpeþení. [online]. 2007 - [2014-04-24].
Dostupné na WWW: http://www.cs.vsb.cz/behalek/vyuka/pcsharp/text/ch09s01.html [6] KLÍMA, Vlastimil. Hašovací funkce, principy, pĜíklady a kolize. [online]. 2005 [cit. 201404-24]. Dostupné z: http://crypto-world.info/klima/2005/cryptofest_2005.htm#_Toc98987052 [7] BELLARE. Hash Functions. [online]. 2005 [cit. 2014-04-24]. Dostupné z: http://webcache.googleusercontent.com/search?q=cache:QkjY_hEF2JgJ:cseweb.ucsd.edu/~m ihir/cse207/w-hash.pdf+hash+funkce&hl=cs&gl=cz [8] BURDA, Karel. Bezpeþnost informaþních systémĤ. 1. Brno: FEKT VUT Brno, 2005 [cit. 2014-04-24]. [9] POSPÍŠIL, Radek. Elektrorevue: Autentizace v poþítaþových sítích a návrh mechanismu jednorázového navýšení uživatelských práv. [online]. s. 10 [cit. 2014-04-24]. Dostupné z:http://webcache.googleusercontent.com/search?q=cache:LKGvHduZKG8J:www.elektrorev ue.cz/cz/download/autentizace-v-pocitacovych-sitich-a-navrh-mechanismu-jednorazovehonavyseni-uzivatelskych-prav/+&cd=2&hl=cs&ct=clnk&gl=cz [10] Retail news update: Benefits and weaknesses of different types of authentication [online]. [2008- ] , January 1, 2008 [cit. 2014-04-24]. Dostupný z WWW:
.
- 53 -
[11] VRÁNA, Jakub. Bezpeþné pĜihlašování uživatelĤ. ROOT.CZ [online].12.4.2006, [cit. 2014-04-24]. Dostupný z WWW:www.root.cz/clanky/bezpecne-prihlasovani-uzivatelu. [12] FEKT VUT V BRNċ. Bezpeþnost informaþních systému [online]. [cit. 2014-04-24]. [13] QR Generator: Qr þteþka [online]. [cit. 2014-04-24]. Dostupné z: http://www.qrgenerator.cz/qr-ctecka/ [14] QR Generator: Qr generátor [online]. [cit. 2014-04-24]. Dostupné z: http://www.qrkody.cz/qr-generator [15] QRcodes.cz [online]. [cit. 2014-04-24]. Dostupné z: http://www.qrcodes.cz/?cat=1 [16] Kryptografie [online]. [cit. 2014-04-24]. Dostupné z: http://kryptografie.ic.cz/kryptografie.php [17] Kryptografie. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-24]. Dostupné z: http://cs.wikipedia.org/wiki/Kryptografie [18] KLÍMA, Vlastimil. Základy moderní kryptologie - Symetrická kryptografie II. [online]. [cit. 2014-04-24]. Dostupné z: http://www.karlin.mff.cuni.cz/~tuma/nciphers/Symetricka_kryptografie_II.pdf [19] DOSEDċL, T. Poþítaþová bezpeþnost a ochrana dat. Brno: Computer Press, 2004. 190 s. ISBN 80-251-0106-1[cit. 2014-04-24]. [20] PINKAVA, Jaroslav. Nové smČry v kryptografii s veĜejným klíþem [online]. c2003 [cit. 2014-04-24]. Text v þeštinČ. Dostupný z WWW:
. [21] HUĕKA, Tomáš. Technologie poþítaþových sítí: Radius [online]. 2005 [cit. 2014-0424]. Dostupné z: http://www.cs.vsb.cz/grygarek/TPS/projekty/0405Z/RADIUS/index.html#2. RADIUS [22] HAJNÝ, Jan. AUTHENTICATION PROTOCOLS AND PRIVACY PROTECTION. VUT Brno, 2012[online]. s. 125 [cit. 2014-04-24]. Dostupné z: http://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=59108. DIZERTAýNÍ PRÁCE. VUT Brno. [23] LEE, Wei-Meng. Beginning Android application development [online]. Indianapolis, IN: Wiley Pub., c2011, 428 p. [cit. 2014-04-24]. Wrox beginning guides. ISBN 978-111-8087800.
- 54 -
[24] SvČt Androida. [online]. [cit. 2014-04-24]. Dostupné z: http://www.svetandroida.cz/kratke-ohlednuti-za-historii-androidu-201305 [25] Elitec software: Vývoj pro android. [online]. [cit. 2014-04-24]. Dostupné z: http://www.elitecsoftware.cz/vyvoj-pro-android/ [26] Android Developers: Get the Android SDK. [online]. [cit. 2014-04-24]. Dostupné z: http://developer.android.com/sdk/index.html [27] HAJNY, Jan a Lukáš MALINA. Unlinkable Attribute-Based Credentials with Practical Revocation
on
Smart-Cards.
[online].
s.
15
[cit.
2014-04-24].
z:http://cardis.iaik.tugraz.at/proceedings/cardis_2012/CARDIS2012_5.pdf
- 55 -
Dostupné
Seznam zkratek QR
Quick Response - dvojrozmČrné kódy
MD5
Message Digest Algorithm - šifrovací hash funkce
UDP
User Datagram Protocol - protokol transportní vrstvy
IP
Internet Protocol - identifikuje síĢové rozhraní v poþítaþové síti
JAVA SE
Java Platform, Standard Edition - definice bČhového prostĜedí
API
Application Programming Interface - rozhraní pro programování
SHA
Secure Hash Algorithm - rozšíĜená hašovací funkce
HASH
hash function – hashovací funkce
USB
Universal Serial Bus
PDA
Personal Digital Assistant – malý kapesní poþítaþ
OHA
Open Handset Alliance
OS
Operation System – operaþní systém
DVM
Dalvik Virtual Machine – Dalvik virtuální stroj
JVM
Java Virtual Machine – Java virtuální stroj
ADT
Android Development Tools – Android vývojové nástroje
SDK
Software Development Kit – sada softwarových vývojových nástrojĤ
SRC
Source code – zdrojový kód
RES
Resource files – soubory zdrojĤ
BIN
Binary Code – pĜeložené binární soubory
GEN
Generated Code – generované zdrojové kódy
V
Publisher – vydavatel
RR
Revocation Referee - revokaþní rozhodþí
U
User – uživatel
- 56 -
O
Verifier – ovČĜovatel
AVD
Android Virtual Device – virtuální Android zaĜízení
- 57 -
Seznam pĜíloh PĜíloha 1 CD obsahující: •
dĞĐŚŶŝĐŬŽƵnjƉƌĄǀƵĚŝƉůŽŵŽǀĠƉƌĄĐĞǀĞĨŽƌŵĄƚƵW&ǀƐŽƵďŽƌƵdžďĞůŝŬϬϯ͘ƉĚĨ
•
^ůŽǎŬĂnjĂƉůŝŬĂĐŝůŝĞŶƚĂsĞƌŝĨŝĞƌŽďƐĂŚƵũşĐşnjĚƌŽũŽǀĠŬſĚLJ͗ o ĐůŝĞŶƚ o ƉƌŽƚŽŬŽů o ƉƌŽƚŽŬŽů͘ƚĞƐƚ o ƌĞĂĚĞƌ o ǀĞƌŝĨŝĞƌ o njdžŝŶŐ͘ĐŽƌĞ o ĐŽƌĞ
•
ƐůŽǎŬĂƐĞƐƉƵƐƚŝƚĞůŶljŵŝǀĞƌnjĞŵŝĂƉůŝŬĂĐş͗ o ĐůŝĞŶƚ͘ĂƉŬ o ǀĞƌŝĨŝĞƌ͘ĂƉŬ
• soubor ve formátu PDF s názvem protokol_test.pdf, kde je ovČĜená funkþnost protokolu a jeho hodnoty
- 58 -