-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdi-pub.tex
3414 lines (2691 loc) · 148 KB
/
di-pub.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
% Created 2015-11-20 pe 13:56
\documentclass[12pt,a4paper,english]{tutthesis}
% Note that you must choose either Finnish or English here and there in this
% file.
% Other options for document class
% ,twoside,openright % If printing on both sides (>80 pages)
% ,twocolumn % Can be used in lab reports, not in theses
% Ensure the correct Pdf size (not needed in all environments)
\special{papersize=210mm,297mm}
% LaTeX file for BSC/MSc theses and lab reports.
% Requires the class file (=template) tutthesis.cls, tut-logo,
% exampleFig (as pdf or eps) and example_code.c
% Author: Sami Paavilainen (2006)
% Modified: Heikki Huttunen (@tut.fi) 2012-07-31
% Erno Salminen (@tut.fi) 2014-08-15
% - added text snippets from the writing guide
% - added lots of comments: both tips and alternative styles
% - added an example table
% - and so on...
\usepackage[finnish, english]{babel}
%
% Define your basic information
%
\author{Riku Itäpuro}
\title{Thesis title} % primary title (for front page)
\titleB{Otsikko suomeksi} % translated title for abstract
\thesistype{Master of Science thesis} % or Bachelor of Science, Laboratory Report...
\examiner{Vilma Valkky} % without title Prof., Dr., MSc or such
% Special trick to use internal macros outside the cls file
% (e.g. @author). Trick is reversed with makeatother a bit later.
\makeatletter
% Define the pdf document properties
\hypersetup{
pdftitle={\@title},
pdfauthor={\@author},
pdfkeywords={transmogrifier design analysis}
}
%% siirsin documentclassin lähelle \usepackage[finnish,english]{babel}
\author{Riku Itäpuro}
\titleB{Älypuhelin kotiverkkojen luottamusankkurina}
% Ensure the correct Pdf size (not needed in all #+LATEX_HEADER: \special{papersize=210mm,297mm}
\thesistype{Master of Science thesis}
\examiner{Jarmo Harju}
\makeatletter
\usepackage{svg}
\usepackage{pstricks}
\usepackage[utf8]{inputenc}
\usepackage{lastpage}
\usepackage[all]{nowidow}
\usepackage{url}
\author{Riku Itäpuro}
\date{18.11.2015}
\title{}
\hypersetup{
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 24.4.1 (Org mode 8.2.10)}}
\begin{document}
\hypersetup{
pdfkeywords={authentication, authorization, AAA, homenet, smartphone, trust anchor, EAP-SIM, RADIUS}
}
\title{Smartphone as home network's trust anchor}
\newpage % Added 2015-02-22
\pagenumbering{Roman}
\pagestyle{headings}
% \begin{document}
% title page
\thispagestyle{empty}
%%%\date\today
\vspace*{-.5cm}\noindent
\includegraphics[width=8cm]{tty_tut_logo} % Bilingual logo
%\title{Smartphone as a trust anchor for delegated home net configuration management}
% lay out author, title and type
\vspace{6.8cm}
\maketitle
%\vspace{7.7cm} % -> 6.7cm if thesis title needs two lines
\vspace{6.7cm} % -> 6.7cm if thesis title needs two lines
% Last some additional info to the bottom-right corner
\begin{flushright}
\begin{minipage}[c]{6.8cm}
\begin{spacing}{1.0}
%\textsf{Tarkastaja: Prof. \@examiner}\\
%\textsf{Tarkastaja ja aihe hyväksytty}\\
%\textsf{xxxxxxx tiedekuntaneuvoston}\\
%\textsf{kokouksessa 4.2.2015}\\
\textsf{Examiner: Prof. \@examiner}\\
\textsf{Supervisor: M.Sc. Bilhanan Silverajan}\\
\textsf{Examiner and topic approved by the}\\
\textsf{Faculty Council of the Faculty of} \\
\textsf{Computing and Electrical Engineering} \\
\textsf{on 4th February 2015}\\
\end{spacing}
\end{minipage}
\end{flushright}
% Leave the backside of title page empty in twoside mode
\if@twoside
\clearpage
\fi
\pagenumbering{roman}
\setcounter{page}{0} % Start numbering from zero because command 'chapter*' does page break
%%% \begin{otherlanguage}{english} % Following text in in 2nd language
\chapter*{Abstract}
\begin{spacing}{1.0}
{\bf \textsf{\MakeUppercase{\@author}}}: \textsf{\@title}\\ % use \@titleB when thesis is in Finnish
\textsf{Tampere University of Technology}\\
% \textsf{\@thesistype, \pageref{LastPage}-5 pages, 5 Appendix pages} \\
\textsf{\@thesistype, 63 pages, 5 Appendix pages} \\
\textsf{November 2015}\\
\textsf{Master's Degree Programme in Information Technology}\\
\textsf{Major: Information Security}\\
\textsf{Examiner: Prof. \@examiner}\\ %
\textsf{Supervisor: M.Sc. Bilhanan Silverajan}\\ %
\textsf{Keywords: authentication, authorization, AAA, homenet, home networks, smartphone, SIM, trust-anchor, EAP-SIM, RADIUS}\\
\end{spacing}
%---------------------------------------------------------
% A B S T R A C T
% [The abstract is a concise 1-page descriptionof the work:
% [what was the problem, what was done, and what are the results. ]
% Do not include charts or tables in the abstract.
Today, home networks are complex, and the home owners
do not necessarily want to administer all aspects of their networks.
Configuring home network devices does not differ much from configuring enterprise devices. One needs access, credentials to login and knowledge to operate the device. If the configuration is outsourced to external parties and
done remotely, those requirements need adaptation.
% implementation,adjustment, fulfilling,
Access to an end device from the outside must be provided, a trusted operator must be hired, and login credentials shared.
For this purpose, some previously set provisioning and distribution of authentication keys is needed.
In this work, an application running on a user's smartphone represents this trusted operator.
The fact that the mobile phone subscribers already are part of a reliable infrastructure
is used in the study as a trusted base.
To benefit from the mobile identification, it is shown how the authentication
and authorization are done using an extendable authentication profile (EAP) and a SIM card.
A theory to use EAP-SIM authentication at home is presented, and
to demonstrate that it works, a simulated testbed
is built, tested, and analyzed.
The idea is to reuse existing techniques by combining them with such new areas as homenet and delegated management.
% For transporting authentication claims, WPA2 Enterprise including RADIUS environment has been chosen.
Authentication claims are transported with WPA2 Enterprise.
To further avoid complexity and granularity, we
only use a simple model of management network.
% Getting in to the management network is carried out at home network via EAP-SIM authentication and it is the key element of the thesis.
%As results, it is shown, that smartphone authentication provides a trust anchor
As a result, we show that the smartphone authentication provides a trust anchor
between a configuration agent and the home network.
% The home owner still holds the control but the
The home network management can be controlled via the smartphone while keeping
the local phone user still in control.
% and it is the key element of the thesis.
The benefits of using the SIM are that it is considered strong, and it has a
%The benefits of using the SIM are strong authentication and a
large existing user base, while its disadvantages include
dependency onto the mobile operator. Additionally, there remain challenges
in keeping the SIM's identity private and in disabling unwanted
re-authentications.
%%%\end{otherlanguage} % End on 2nd language part
%---------------------------------------------------------
% T I I V I S T E L M Ä
\begin{otherlanguage}{finnish} % Following text in in 2nd language
\chapter*{Tiivistelmä} % Asterisk * turns numbering off
\begin{spacing}{1.0}
% {\bf \textsf{\MakeUppercase{\@author}}}: \@titleB\\ % or use \@title when thesis is in Finnish
{\bf \textsf{\MakeUppercase{\@author}}}: \textsf{\@titleB}\\ % or use \@title when thesis is in Finnish
%{Älypuhelin kotiverkkojen luottamusankkurina}
\textsf{Tampereen teknillinen yliopisto}\\
\textsf{Diplomityö, 63 sivua, 5 liitesivua}\\ %
\textsf{marraskuu 2015}\\
\textsf{Tietotekniikan koulutusohjelma}\\
\textsf{Pääaine: tietoturva}\\
\textsf{Tarkastaja: Prof. \@examiner}\\ % automated, if just 1 examiner
\textsf{Ohjaaja: M.Sc. Bilhanan Silverajan}\\
\textsf{Avainsanat: tunnistaminen, valtuutus, AAA, homenet, kotiverkko, älypuhelin, SIM, luottamusankkuri, EAP-SIM, RADIUS}\\
\end{spacing}
% The abstract in Finnish. Foreign students do not need this page.
% Kirjoita, kun english versio on hyvä(ksytty).
Kun tietoverkot kodeissa monimutkaistuvat, eivät kotikäyttäjät
osaa tai halua enää ylläpitää niitä. Kotiverkkojen ylläpito ei
eroa nykyisin paljon yritysympäristöistä. Käyttäjältä vaaditaan
läsnäolo, tunnukset ja tietämys laitteiden operointiin. Näitä
vaatimuksia
% täytyy muokata? soveltaa
täytyy soveltaa, jos ylläpito ulkoistettaisiin ja pääsy
kotiverkkoihin sallittaisiin. Luotettava toimija on palkattava
ja jaettava tälle tunnistautumiskeino sekä pääsy kohdelaitteelle
ulkoa käsin. Tämä edellyttää ennakkotoimia ja tunnistautumisavainten jakelua.
Käyttäjän älypuhelimessa toimiva sovellus toimii tässä luotettuna toimijana.
% Tutkielma kuvaa tätä toimijaa sovelluksena käyttäjän älypuhelimessa.
Matkapuhelinliittymällään käyttäjä on jo osa luotettua
tilaajarekisteriä, ja tätä ominaisuutta käytetään hyväksi työssä
luottamuksen rakentajana. Matkapuhelintunnistuksena käytetään
SIM-kortin tilaajatietoa EAP-menetelmällä.
% Pääsynvalvonta hoidetaan RADIUS-protokollalla.
EAP-SIM-pohjaisen tunnistuksen toimivuus esitetään
käyttöympäristössä, jossa on simuloitu SIM-kortti ja matkapuhelinoperaattori.
Periaatteena on ollut käyttää
olemassaolevia tekniikoita yhdistäen niitä uusiin alueisiin,
kuten homenet-määritysten kotiverkkoihin ja edustajalle ulkoistettuun
hallintaan. Tunnistus- ja valtuutustietojen välittämisen hoitaa
WPA2 Enterprise RADIUS-ympäristössä. Välttääksemme
monimutkaisuutta ja tarpeetonta hienorakeisuutta, käytämme yksinkertaista
hallintaverkkomallia, jonka rajalla on kotiverkosta muuten
erillään oleva älypuhelin.
% Päästäkseen hallintaverkkoon, on älypuhelimen läpäistävä
% EAP-SIM tunnistus, mikä luo luottamusankkurin
Tuloksena näytetään, että matkapuhelimella tehty tunnistautuminen luo
luottamusankkurin ulkoisen edustajan ja kodin hallintaverkon välille avaten edustajalle hallintayhteyden kotikäyttäjän valvonnassa.
SIM-tunnistuksen hyötyjä ovat vahva tunnistus
ja laaja käyttäjäkanta. Haittoina ovat
riippuvuus teleoperaattorista, käyttäjän identiteetin
paljastumisen uhka ja ei-toivottu automaattinen tunnistautuminen.
\end{otherlanguage}
%\end{otherlanguage}{finnish} % End on 2nd language part
% varmuuden vuoksi, sillä esim. captioneissa Kuva tulee muuten suomeksi
%%% \begin{otherlanguage}{english} % Following text in in 2nd language
\begin{otherlanguage}{english} % Following text in in 2nd language
\makeatother % Make the @ a special symbol again, as \@author and \@title are not neded after this
%
% PREFACE
%
\chapter*{Preface}
This thesis is dedicated to my father.
I wrote this thesis during my research assistant period at TUT.
It took time approximately 9 months to start these final words on preface,
taking into account my part time job.
Although I had some earlier experience on some of the techniques involved in this paper,
other techniques were quite new to me, not to mention writing a longer
science related paper. Writing and studying all this was equally fun,
but now it is time to let go.
There were many people involved in the creation process of this thesis.
Bilhanan Silverajan took care of introducing me in to this topic of
home networking and worked as my supervising instructor.
Jarmo Harju as the examiner, helped in technical proofreading and
corrected some of my speling errors, but Pirkko, my friend, was the ultimate inspiration
and the aid for the rest of the forgotten articles and misplaced commas.
Antti, Axu, Joona, Lauri, Mava, Pekka, and Tiina among others were
the uplifting spirit at work.
Those pervs made my working in the Pervasive Computing unit a pleasure.
At home front the one power cell, who kept me going and always encouraged me
was my beloved wife Päivi.
Thank you all!
~
% Tilde ~ makes an non-breakable spce in LaTeX. Here it is used to get
% two consecutive paragraph breaks
Tampere, November 20th, 2015
~
Riku Itäpuro
%OpenPGP fingerprint: A4B2 936C E01E 9FEC 10FE 441F 7F09 442C 236D 9400
%
% Add the table of contents, optionally also the lists of figures,
% tables and codes.
%
\renewcommand\contentsname{Table of Contents} % Set English name (otherwise bilingual babel might break this), 2014-09-01
%\renewcommand\contentsname{Sis<E4>llys} % Set Finnish name
\setcounter{tocdepth}{3} % How many header level are included
%% ei tähän vielä
% latexin \tableofcontens clearaa yhden käytön jälkeen, siksi tässä tyhjä.
% Yritä kieltää se ennen tätä.
% ks. http://orgmode.org/manual/Table-of-contents.html
\tableofcontents % Create TOC
\renewcommand\listfigurename{List of Figures} % Set English name (otherwise bilingual babel might break this)
%\renewcommand\listfigurename{Kuvaluettelo} % Set Finnish name
\listoffigures % Optional: create the list of figures
\markboth{}{} % no headers
\renewcommand\listtablename{List of Tables} % Set English name (otherwise bilingual babel might break this)
%\renewcommand\listtablename{Taulukkoluettelo} % Set Finnish name
\listoftables % Optional: create the list of tables
\markboth{}{} % no headers
%\renewcommand\lstlistlistingname{List of Programs} % Set English name (otherwise bilingual babel might break this)
%%\renewcommand\lstlistlistingname{Ohjelmaluettelo} % SetFinnish name, remove this if using English
\lstlistoflistings % Optional: create the list of program codes
%\markboth{}{} % no headers
%
% Term and symbol exaplanations use a special list type
%
%\chapter*{List of abbreviations and symbols}
\chapter*{List of abbreviations}
%\chapter*{Lyhenteet ja merkinn<E4>t}
\markboth{}{} % no headers
% You do not have to align these with whitespaces, but it makes the
% .tex file more readable
\begin{termlist}
% \item [CC license] Creative Commons license
% \item [LaTeX] Typesetting system for scientific documentation
% \item [SI system] Syst\`eme international d'unit's, International System of Units
% \item [URL] Uniform Resource Locator
\item[3GPP] $3^{rd}$ Generation Partnership Project
\item[AAA] Authentication, Authorization, Accounting
\item[AKA] Authentication and Key Agreement %, used in 3GPP mobile networks
\item[AuC] Authentication Center
\item[CPE] Customer Premise Equipment %, device physically located at customers home.
\item[EAP] Extensible Authentication Protocol %, extends 802.1X
\item[ETSI] European Telecommunications Standards Institute
\item[GAA] Generic Authentication Architecture % (for SSO)
\item[GBA] Generic Bootstrapping Architecture, 3GPP standard for user authentication with help of shared key from operator, part pf GAA.
\item[GSM] Global System for Mobile Communication (earlier Groupe Spécial Mobile)
\item[HLR] Home Location Registry
% \item[ICCID] card serial
\item[IEEE] Institute of Electrical and Electronics Engineers
\item[IMSI] International Mobile Subscriber Identity
\item[ISP] Internet Service Provider
\item[MITM] Man-in-the-Middle
\item[MNO] Mobile Network Operator
\item[MSS] Mobile Signature Services
\item[MSISDN] Mobile Station Integrated Services Digital Network, user's phone number
\item[RADIUS] Remote Authentication Dial In User Service, protocol and server, AAA service
\item[SIM] Subscriber Identity Module, a smartcard. Also USIM program running in UICC card (UMTS networks)
\item[SSID] Service Set Identifier, identifies Wi-Fi network
\item[TMSI] Temporal Mobile Subscriber Identity
\item [TUT] Tampere University of Technology
\item[USIM] Universal Subscriber Identity Module
\item[UICC] Universal Integrated Circuit Card
\item[Wi-Fi] Wireless local network, implements IEEE 802.11 standards
\item[WPA] Wireless Protected Access version 1
\item[WPA2] Wireless Protected Access version 2
\end{termlist}
% The abbreviations and symbols used in the thesis are collected into a
% list in alphabetical order. In addition, they are explained upon
% first usage in the text.
\newpage
\chapter*{Terminology}
%\chapter*{Lyhenteet ja merkinn<E4>t}
\markboth{}{} % no headers
\begin{description}
\item[{802.1X}] port-based access control standard
\item[{access point, AP}] connects wireless (Wi-Fi) clients to a wired network,
used here to encapsulate EAP messages to RADIUS and
to forward them to an authentication server
\end{description}
\begin{description}
\item[{authentication server}] a server checking identity claims, for
example RADIUS server
\item[{authenticator}] a local entity that makes the authentication (and
authorization) decision for a client based on local and remote
claims, part of 802.1X standard
\end{description}
\begin{description}
\item[{mobile (network) operator, MNO}] a mobile network operator, knows the connection
between a SIM-owner and SIM secrets
\end{description}
\begin{description}
\item[{proxying RADIUS}] RADIUS server standing between a RADIUS
client and an authentication server, part of RADIUS server chain
\end{description}
% The actual text begins here and page numbering changes to 1,2...
% Leave the backside of title empty in twoside mode
\if@twoside
\cleardoublepage
\fi
\newpage % Added 2014-09-01
\pagenumbering{arabic}
\setcounter{page}{1} % Start numbering from zero because command
% 'chapter*' does page break
\renewcommand{\chaptername}{} % This disables the prefix 'Chapter' or
% 'Luku' in page headers (in 'twoside'
% mode)
\chapter{Introduction}
\label{sec-1}
\label{cha:intro}
Managing computer and network devices can be hard. Modern homes have
become similar to small offices regarding the equipment present in them.
Earlier, it was sufficient to make just minimal settings at home to a
modem (cable, phone or radio) and to connect it to the home computer to
get a fully working home network with internet connectivity. Today,
the home
network has expanded with countless devices available.
Entertainment centers (AV-amplifiers, media players, game consoles),
manageable network devices (switches/routers), and mobile phones
represent new devices and network segments beside computers and
printers. Sensors and controller devices from the Internet of Things
domain bring their own increment to the device count at home.
Connecting these devices to the network remains trivial, but managing the
network afterwards has become challenging and complex.
There might be separate areas in homes that have different needs regarding
connectivity, resources, and access. In addition, devices in
separate segments may not belong to the home owner anymore, hence needing
their own administrative parties. For example, an electricity company may
have a sensor and controller network, which physically uses the home network, but
is logically separated from the other parts of the home network. It is therefore
important to keep track of who is allowed to access the different parts of the
home network.
The configuration choices in networking devices take some
amount of expertise that is not necessarily present at every
home. There could exist a market for an external consultant service, which would
remotely manage the home network.
Remote management eliminates the consultant's
physical presence at home and so reduces external actors' costs, but adds many questions
regarding security, not only to overcome firewalls, NATs, and
the disconnectivity from the Internet.
Persons who are allowed to make configuration changes are today
often authenticated only by a simple password and physical presence at home.
If external help was present, the home owner would need more
control allowing only authorized operators in, because the
protection used earlier would be missing.
Finally, it is challenging to find a common,
trusted entity, upon which every actor could base their trust.
Mutual trust
is needed to join the formerly unknown parties together
safely.
In summary, the problems are the delegated network management, remote
provisioning, and trust finding. At its roots, this is an authentication
and authorization problem.
One model to solve these problems is to separate the management and
control functions from the connectivity and routing
issues. Silverajan et al. \cite{silverajan2015collaborative} proposes
a model where the management is achieved through a service in a cloud.
The cloud service is of type Backend-as-a-Service (BaaS) which is well
suited for mobile application usage. The
configuration model of devices in a home is mirrored to the cloud as a
resource graph.
Changes can be planned ahead in the cloud
and committed (Pushed) later to the home using configuration
tools
running over CoAP (Constrained Application Protocol)
via a local controller point located at home.
CoAP is suitable for IoT devices having constrained resources.
The managers operate in the cloud with the configuration data and the
cloud verifies those managers,
but the question that remains is how to connect the cloud service to the home network
through the local controller securely. The local controller at home
would approve the changes, and a smartphone is assumed to function in
the local controller role. It will operate as a bridge between the cloud and the home network.
See Figure\ref{fig:localcontroller} for the design of this architecture.
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{localcontroller.png}
\caption{\label{fig:localcontroller}Local Controller and Collaborative Management Design}
\end{figure}
The delegated service provider therefore does not need to have a direct data
access to the home but only to the cloud-based service in order to be able to
manage the home network devices.
Consultant service is not the only possible delegation for a home network.
One of the security issues is the authentication and authorization
from the cloud to the home network.
To secure the connection from the cloud service (remote controller)
to the home network, there needs to be a mutual trust between the end
points, and the research problem here is how to enable the trust between the
local controller and the home network as the local controller lies at the edge of the
home network. The connection between the remote and local
controller is assumed to already be trusted.
Any encryption between devices needs trusted key exchange beforehand,
and finding and establishing trust is needed for that. That is called
the key distribution problem. Public and private keys solve the key exchange part, but
only partially, because the trust still must be found somewhere.
The trust can be derived from the facts that already are known.
The ultimate trust can be achieved by verifying the trust chains
until the chain reaches a trust anchor.
The trust anchor is the fact, state, or place,
where the derivation of trust is no longer done, but accepted per se.
Combining existing techniques, this thesis presents one possible way
to bind the home network's trust to the smartphone's unique, existing
secret keys inside the smart card's Subscriber Identify Module (SIM),
which then would function as a trust anchor.
The above mentioned cloud solution for delegated home network
management currently has a preliminary authentication and access model
using pre-defined credentials for accessing the local network in general, and other
credentials for secure SSH-connection from the local
controller device to configuration
targets \cite[Chap.4]{silverajan2015collaborative}.
That does not yet handle the bootstrap of the
infrastructure, i.e., the first trust is taken as given.
The smartphone with its SIM and an
existing key infrastructure to the mobile
network operator (MNO) would later eliminate the requirement for an
additional credential distribution. That issue is studied in this
thesis. Although the smartphone provides an alternative authentication
method with its SIM key, usual methods to authenticate are still plain
username-password combinations. This security issue must be solved
before delegation in the cloud can happen.
The goal presented in Figure\ref{fig:intro-goal} is to make the smartphone a central, trusted controlling
point for managing purposes. The normal access between the
Internet and the home network should stay unchanged.
The human aspect and usability are also important, but the focus will
still be on the authentication and authorization part of the home net
management with smartphone as a trust anchor. The proposed model
should nevertheless require less effort than the currently used methods
on distributing user credentials, finding the right place for them to be
inserted, and ensuring that they are written correctly.
Besides those, problems such as limited connectivity are
studied.
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{intro-goal.png}
\caption{\label{fig:intro-goal}Goal of the thesis}
\end{figure}
The thesis is structured as follows: authentication--authorization
model is explained in Chapter \ref{sec-2}. Chapter \ref{sec-3}
describes security in current home network architecture and
practices for configuring it. Chapter \ref{sec-4} discusses methods
to bring a trust anchor into the home network and explains the chosen
method.
One specially crafted problem is how the scenarios presented here can be
tested without knowing the SIM card's secret keys and without a real phone
operator involved. Those experiments are described in Chapter \ref{sec-5}.
Results are discussed in Chapter \ref{sec-6}, and Chapter \ref{sec-7} concludes the
thesis.
\chapter{Authentication, authorization, and trust}
\label{sec-2}
Authentication, authorization, and accounting services (AAA) are
components for access management. AAA-protocols do not dictate
policies, i.e., who is granted an access or what operations a user is
allowed to do. They only transport this information between a client
who needs them and a server authorized to provide them.
Often, the last 'A', which stands for accounting, has been neglected
and also here only the first two 'A's are used and later described as AA
services. Authentication (AuthN) answers the question of how to identify users and
prove that they really are who they claim to be. Authorization (AuthZ)
answers the question of what operations the identified users are allowed to do and
enforces the usage policy. The rest of the thesis uses short terms AuthN
and AuthZ.
In very small environments, AA service is built on a static backend, such
as a file on a protected target that an entity wants to access. There, AuthN
is checked against a credentials file, and AuthZ is given from a service
specific policy file.
To be more exact, the identification preceding the authentication is the part
where the entity claims and presents its identity to the
access controlling system. That can involve sending a username, login
name, or other identifier. Authentication in turn is the part where
those facts are verified. AuthZ involves checking which rights are
available for the authenticated entity.
Before we introduce SIM-based authentication used throughout the
thesis, protocols 802.1X, WPA2, EAP and RADIUS are described in the
following sections. After this, we expand the term \emph{trust}.
\section{802.1X}
\label{sec-2-1}
802.1X \cite{8021X} is an IEEE standard protocol for port-based access
control. Ports are physical layer ports, not to be mixed with Layer-4 ports such as TCP/UDP ports.
Network access through a specific physical port is
restricted (controlled) from a client (called Supplicant) until
the client has successfully performed AA. An 802.1X device, where
the ports are located, is called authenticator. Third party in 802.1X is an
authentication server.
The terms \emph{authenticator} and \emph{authentication server} are easily
mixed, but their roles are different: an authenticator works as a
gate-keeper to the ports between a supplicant and the network, while
an authentication server handles the AA processes.
At home the, authenticator usually lies inside the access point (AP),
which functions also as a router. However, in large enterprise
networks, the authenticator may be a centralized unit,
and multiple access points function only as radio stations without
routing or authenticator properties.
\section{RADIUS}
\label{sec-2-2}
\label{sec:radius}
RADIUS is the most popular provider for the
AAA-services \cite[p.75]{radius-popular}. It was used first with remote terminal
and dial-up modem users, hence the name Remote Authentication Dial-In
User Service. Later, it was used as a centralized AAA for networking
devices such as switches and routers.
RADIUS protocol is a stateless, request-response type client-server
protocol.
There are four types of RADIUS messages defined in RFC2865 that are
used in the AA. ACCESS-REQUEST and ACCESS-CHALLENGE cover both AuthN and
AuthZ messaging, while the final RADIUS message is either
ACCESS-ACCEPT or ACCESS-REJECT, based on the
result given by the final RADIUS server.
Today, RADIUS has some shortcomings and fixing them is no longer
reasonable as development has shifted to another AAA protocol called
Diameter, which is already in use in 3GPP and 4G
networks \cite{diameter}. Nevertheless, as RADIUS is so wide-spread,
it is still used in many places instead of Diameter. Currently,
the main environment of RADIUS, besides AA in network managing, are wireless
connections (Wi-Fi) in enterprises and nationwide community
federations.
When local Wi-Fi groups such as ``SparkNet'', ``Langaton
Tampere'', or ``Wippies'' started to form around 2005 in Finland, they used
802.1X and RADIUS for AA. Those networks did still have as an
alternative AA method a captive portal technique, where the user had to
first authenticate on a WWW-page before getting an access. 802.1X and
RADIUS brought an external, central RADIUS server for the automatic authentication
of requests, without the burden of the captive portal.
The members of the Wi-Fi groups could then use the network in any location where
the same uniform SSID (Service Set Identifier) was seen. Roaming
became possible if one found a familiar SSID outside the home area.
Later, agreements were made between different local groups to allow
roaming, and so federations were born.
As seen from the federated Wi-Fi groups, RADIUS servers can be chained to
form a tree. The reasons for the chaining are load balancing and high
availability, centralization of distant servers, and
a federation of different domains. With a RADIUS hierarchy, the messages
can be proxied to the next RADIUS server in the chain, depending on the settings
on the proxying RADIUS server.
RADIUS messages are normally not protected from eavesdropping, but they have
integrity fields to notice if they have been tampered with.
The integrity field is called a Message Authenticator.
Notice the use of the term \emph{authenticator} in a different context here, not
meaning 802.1X's authenticator.
When using RADIUS to AuthN and AuthZ, Requests can only belong to ACCESS-REQUEST messages while
Responses can be either an ACCESS-ACCEPT, ACCESS-REJECT, or ACCESS-CHALLENGE message.
The Message Authenticator field is sent as last Attribute Value Pair (AVP)
of each RADIUS message, and it can belong
to either Request or Response \cite[p.20]{radiusbook}.
The Request Authenticator is a 16-octet long, random number in an
ACCESS-REQUEST message, but the Response Authenticator for it is achieved
with a one-way MD5 digestion function.
The digest is taken from the concatenation of Code, ID, Length, corresponding
Request\-Auth, Attributes, and a Secret, and can look like
$3fef65608\ldots 2a79$.
\begin{verbatim}
Response Authenticator =
MD5(Code |ID |Length |Request Authenticator |Attributes |Secret)
\end{verbatim}
The Secret is the shared secret which has been configured between
RADIUS client-server pairs,
and it protects some parts of the traffic.
Different RADIUS client-server pairs may use different
shared secrets, and the RADIUS server must separate them according to the client's IP address to
manage proxied RADIUS requests \cite{radiusbook}.
An exception to the above-mentioned plain-text messaging are the user passwords.
If the user password was to be transmitted in RADIUS, it would be sent first
through an exclusive OR (XOR) function together with an MD5 digested Secret
and Request Authenticator.
\begin{center}
{\tt
User-Password = XOR(password, MD5(Secret | Request Authenticator))}
\end{center}
In the following chapters, it is discussed how the proxying servers take
part in the AA decisions. Of main interest there is whether it is possible
to inject or modify AuthZ information in those proxying RADIUSes in
cases where AuthN and AuthZ are provided from different
places \cite{rfc2607}. A secondary goal is to universally divide AA regarding
the client's domain in the federation.
\section{WPA2}
\label{sec-2-3}
A Wireless Protected Access (WPA or WPA2) protects the traffic in a wireless,
shared media, where everyone otherwise can simply listen to all the radio traffic.
WPA2 enables both an authenticated access and a message
encryption between a client device and a wireless access point (AP)
by negotiating session keys. This happens
after 802.1X has opened the virtual port in the AP for the client.
The WPA (version 1) was an early subset of then upcoming 802.11i standard,
while the WPA2 is the full implementation, also denoted as IEEE
802.11i-2004. The term WPA2 is used throughout the thesis.
Client software for 802.11i is called a WPA2-Supplicant, and it is used
in wireless clients to communicate with the authenticator.
The WPA2 has two modes of protection: one for groups with a common, pre-shared
key (WPA2-PSK, also known as WPA2-Personal) and one for individuals
having their own key (WPA2-RADIUS, also known as WPA2-Enterprise). With
WPA2-RADIUS, revoking
individual access is easier, but client setup is slightly more
complicated than on WPA2-PSK, as seen on Table\ref{psk-enterprise}.
\begin{table}[htb]
\caption{\label{psk-enterprise}Comparison of WPA2-PSK and WPA2-ENTERPRISE modes}
\begin{tabular}{l|l|l}
Property & WPA2-PSK & WPA2-ENTERPRISE\\
\hline
suitable for groups & x & \\
suitable for individuals & & x\\
individual client revocation & & x\\
client setup & easy & intermediate\\
\hline
\end{tabular}
\end{table}
\section{EAP}
\label{sec-2-4}
New AuthN methods are invented all the time.
Instead of implementing them into 802.1X, it was
extended with a modular framework called
EAP (Extensible Authentication Protocol) \cite{rfc5247}.
Researchers justify using EAP, as it
provides flexibility independent from underlying technology, whether
wireless or wired, and integration with AAA infrastructures, although
it adds some overhead to AuthN \cite{pereniguez10}.
Different authentication methods, such as hashed passwords, TLS
certificates, or SIM/AKA using smartphone's SIM card, can
be used with EAP.
This work uses the EAP-SIM authentication method.
EAP describes only the messaging form, so EAP messages needs to
be encapsulated inside another protocol. In Wi-Fi, between a smartphone
and an AP, the EAP can be encapsulated into 802.1X protocol (as EAPOL) or
into a protected EAP(PEAP) \cite{peap} before sending
it into air. In a wired network, those EAP messages are translated and encapsulated into RADIUS.
The encapsulation is described in Figure\ref{fig:eap-layers} where it can be
seen that the EAP messaging takes place logically between the EAP peer and
the authentication server. On a lower transport layer between them,
there is an EAP authenticator, which transfers EAPOL messaging into a
RADIUS message.
Furthermore, EAP is used to transfer AuthN messages only.
EAP includes neither AuthZ information, which is RADIUS's
responsibility, nor session keys, which are negotiated by WPA2. In the
end,
the authenticator is responsible for opening access for the EAP peer, as 802.1x
dictates.
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{eap-layer.png}
\caption{\label{fig:eap-layers}EAP-logical layering and encapsulation}
\end{figure}
\section{SIM-based authentication}
\label{sec-2-5}
\label{sec:sim-based-auth}
SIM associates a physical card used in smartphones to
a subscriber of the Mobile Network Operator (MNO).
SIM here means the secret keys and the application in mobile phone's
SIM or USIM inside UICC (Universal Integrated Circuit Card).
The secret keys are hardware-protected and only usable for applications
in a SIM card.
The SIM's storage also includes a unique serial number ICCID
(Integrated Circuit Card Identifier) which identifies the SIM globally,
and a unique IMSI (International Mobile Subscriber Identity). The IMSI is
a composition of digits belonging to the Mobile Country Code (MCC, 2
digits), Mobile Network Code (MNC,2-3 digits), and Mobile Subscriber
Identification Number (MSIN, 10 digits at maximum).
It is not to be mixed with MSISDN (Mobile Station Integrated Services
Digital Network), which is the user's full international phone number.
SIM card usage can be controlled with two passwords: PIN and PUK. PUK
is used as a remedy if PIN has been entered incorrectly too many times.
If the card has other applications, such as a mobile electrical
signature application (see Section \ref{sec:altmethods}),
they may have different keys and codes.
The passwords, keys, and cards are distributed by the MNO.
They
provide the mobile network connectivity to the customers of the MNO. The
secret keys are used for authenticating an IMSI to an MNO, and this
enables MNOs to identify their customer in the network and to charge them
accordingly. The client's identity is verified when the SIM is delivered.
It is assumed that the SIM card represent its owner, but in reality
nothing prevents an identity thief from stealing someone's SIM
card. Although the 4-digit PIN tries to prevent the usage of the
stolen SIM, this is considered a weak safe \cite[p.31]{aaa-nakhjiri2005}.
The most important outcome of this distribution is the achieved trust
between the client and the MNO.
AA services need to trust some entity endpoint. In case of the MNO
and the
SIM, they already mutually trust each other, and the SIM can be used
to open access to the mobile networks.
Access to Wi-Fi networks still needs a separate access credential,
and that was the reason for developing EAP-SIM and later the
derivatives EAP-AKA and EAP-AKA'. The goal was to combine
the existing keys used in GSM (Global system for Mobile communication)
in a secure way to Wi-Fi access. The general purpose EAP-methods existing in 2004 were not
compatible with GSM protocols for this purpose \cite[p.93]{hav-doc}.
The results of that development gave us EAP-types EAP-SIM, EAP-AKA, or
EAP-AKA'(AKA-PRIME).
EAP-SIM is the original type created for GSM networks and defined
in RFC4186 \cite{rfc4186}.
It is a challenge-response method and similar to AuthN used in GSM,
but it adds mutual AuthN; i.e., also the network is authenticated.
Beginning from 3GPP networks, the new types EAP-AKA and AKA' can be used.
EAP-AKA is defined in RFC4187 \cite{rfc4187} and
uses the 3GPP's AKA (Authentication and Key Agreement) protocol.
It adds to EAP-SIM additional parameters \cite{rfc5448}, such as
sequence numbering from the MNO to protect replay attacks and more
advanced digestion functions instead of SHA-1.
Otherwise the protocol messaging is same as in EAP-SIM.
Finally, there exists EAP-AKA' that enhances AKA by including a Service Set
Identifier (SSID)
in the key derivation function, which limits the possibility of using possibly
compromised network's nodes and keys.
Using EAP-SIM means using the secret key inside a SIM card with A3/A8
algorithms to generate valid responses for the challenges coming from
an MNO and to derive session keys. The algorithms A3/A8 and their
possible implementations (COMP128, COMP128v2, COMPv3) are not of
interest in this work. They can be MNO specific or known reference algorithms.
EAP-SIM variants provide strong AuthN, which here means two-factor
AuthN. One factor is something you own (the physical SIM card) while another
is something you know (the SIM card's PIN). Biometric factor, i.e., what you are,
is not used here, but that would be a third possible factor.
Software-based certificates, while stronger than regular passwords, do
not, on the other hand, possess the properties \emph{non-copiable} or
\emph{unique}, so they can only be considered as strong passwords and do
not fulfill the requirements for two-factor AuthN. If we
nonetheless were using software certificates with a method such as
EAP-TLS, then the certificates (for CA and client) and the private key
should still be provisioned first, which would defeat what we want to
achieve in easy user experience.
Disadvantages with SIM are the dependency on the mobile operator and internet
connection, although disconnectivity issues are later addressed
partly in Section \ref{sec:disconnections}.
Using a smartphone may cost money, either to the client or to the service
provider, but the costs could be lower than using an SMS, because
the network used is an IP network instead of a cellular phone network.
In many parts, SIM variants of EAP are simpler than other EAP
variants to the mobile client. Table\ref{table-peapsim} compares the setup of Wi-Fi
in clients of one existing organization to EAP-SIM. The example
is taken from setting up Nokia Communicator model E90, but in general,
the same options are also needed for other clients, also with laptops. It
is noteworthy that plain EAP-SIM will not support identity
hiding. This will be discussed further later on. If we also added PEAP
to EAP-SIM (in last column of Table\ref{table-peapsim}), the comparison would be more fair.
As can be seen from the table, leaving certificates out from the environment
makes the client setup easier with the price of revealing the smartphone user's
identity.
\begin{table}[htb]
\caption{\label{table-peapsim}WPA2-Enterprise client setup with EAP-PEAP-MSCHAPv2 and EAP-SIM}
\centering
\begin{tabular}{l|l|l|l}
& EAP-PEAP & EAP-SIM & EAP-PEAP\\
Task: & with & & with\\
(x)=``needed'', (N/A)= ``not available'' & MSCHAPv2 & & EAP-SIM\\
\hline
CA settings: & & & \\
- choose CA for the RADIUS & x & & x\\
- if CA-key not known, fetch \emph{securely} & x & & x\\
\hline
Other settings: & & & \\
- used EAP-method & x & x & x\\
- validation of RADIUS server's name & x & & x\\
- encapsulation (WPA2/802.1X) & x & & \\
- password & x & x(PIN) & \\
\hline
Identity hiding: & & & \\
- enable PEAP & x & N/A & x\\
- outer identity & x & N/A & x\\
- inner identity & x & N/A & \\
\hline
\end{tabular}
\end{table}