1
00:00:00,000 --> 00:00:10,667
[Translated by Kari Kananoja (ITKST56 course assignment at JYU.FI)] Alkumusiikkia

2
00:00:12,235 --> 00:00:17,520
Seuraavassa keskustelussamme on mukana Jo Van Bulk ja Fritz Adler 
belgialaisesta Leuvenin

3
00:00:17,520 --> 00:00:24,640
yliopistosta ja David Oswald, kyberturvallisuuden 
professori Birminghamista.

4
00:00:24,640 --> 00:00:29,840
He ovat täällä keskustelemassa luotetusta toiminto/ajoympäristöstä (TEE)
(laitteen eristetty prosessorin osa, johon esim. laitteen käyttöjärjestelmällä ei ole pääsyä).

5
00:00:29,840 --> 00:00:36,320
Tiedättekin varmasti Intelin ja vastaavien perusteella, että siihen eli luultavasti pitäisi luottaa lainkaan,

6
00:00:36,320 --> 00:00:42,160
koska se on ohjelmoitua ja siinä on virheensä. Niinpä he puhuvatkin nyt

7
00:00:42,160 --> 00:00:47,680
prosessorin enklaaviportteihin iskemisestä,
mikä on aina hyvä, järjestelmällisen haavoittuvuuden

8
00:00:47,680 --> 00:00:52,080
arviointikohde TEEn suojauksessa. Olkaa hyvät ja jatkakaa.

9
00:00:52,080 --> 00:00:58,690
Hei kaikille. Tervetuloa mukaan keskusteluun. Olen Jo, imec-DistriNet

10
00:00:58,690 --> 00:01:02,640
tutkimusryhmän perustaja Leuvenin yliopistolla.
Ja tänään mukana on myös Fritz, myös Leuvenista

11
00:01:02,640 --> 00:01:06,800
ja David Birminghamin yliopistosta. Meillä on tämä hyvin kiinnostava

12
00:01:06,800 --> 00:01:11,440
aihe keskusteltavana, enklaaviportteihin iskeminen. Mutta ennen kuin syvennymme siihen,

13
00:01:11,440 --> 00:01:16,400
uskon että suurin osa teistä 
ei tiedä mitä ovat enklaavit, tai yleensä TEEt

14
00:01:16,400 --> 00:01:23,520
Joten aloitankin tässä analogialla. Enklaavit ovat eräänlaisia

15
00:01:23,520 --> 00:01:29,520
turvallisuuslinnakkeita prosessoreissa, CPUissa. 
Se on siis kryptattu muistialue,

16
00:01:29,520 --> 00:01:36,960
johon on pääsy vain TEEn sisäpuolelta. Mitä tiedämme

17
00:01:36,960 --> 00:01:41,560
linnoitusten puolustautumisen ja niihin hyökkäysten historiasta, kun et

18
00:01:41,560 --> 00:01:46,560
pääse linnoitukseen koska seinät ovat korkeita ja paksuja. parasta onkin suunnata porteille.

19
00:01:46,560 --> 00:01:51,280
Se on linnoituksen heikoin kohta. Ja se on

20
00:01:51,280 --> 00:01:57,440
tämän aiheemme idea. Se siis pätee myös enklaaveihin. Me olemme

21
00:01:57,440 --> 00:02:01,520
iskeneet enklaavien portteihin, olemme hyökänneet syöte- ja tulosterajapintoihin.

22
00:02:01,520 --> 00:02:07,600
Siis hyvin yksinkertainen idea, mutta dramaattiset vaikutukset, sanoisin.

23
00:02:07,600 --> 00:02:14,640
Tämä on siis jonkinlainen päätelmä tutkimuksistamme. 40 rajapinnan

24
00:02:14,640 --> 00:02:20,480
huoltoon liittyvää 
haavoittuvuutta jotka löysimme kahdeksassa paljon käytetyssä openvapaan lähdekoodin

25
00:02:20,480 --> 00:02:27,040
projektissa. Menemme tähän hiukan syvemmälle lopuissa dioissa.

26
00:02:27,040 --> 00:02:32,400
On mukavaa sanoa, että 
se on johtanut kahteen akateemiseen julkaisuun,

27
00:02:32,400 --> 00:02:38,880
enemmän kuin 7 CVE-tietoon ja 
kokonaisuudessaan melko hallittuun loppuun käsittelyyn ja

28
00:02:38,880 --> 00:02:46,095
pitkiin käytön rajoituksiin. 
OK, Meidän täytynee

29
00:02:46,095 --> 00:02:55,197
keskustella miksi me yleensä tarvitsemme moisia enklaavi linnoituksia. 
Jos mietitään

30
00:02:55,197 --> 00:03:00,230
Jos mietitään perinteistä käyttöjärjestelmä-tai tietokonearkkitehtuuria, siinä on

31
00:03:00,230 --> 00:03:06,131
käytössä 
hyvin laaja luotettu toimintoperusta. Esimerkiksi, jos katselet tätä keskustelua esim. kannettavalta

32
00:03:06,131 --> 00:03:12,265
luotat kerneliin, 
luotat ehkä

33
00:03:12,265 --> 00:03:16,909
virtuaalikoneeseen jos sinulla on koko ympäristö toteutettuna: CPU,

34
00:03:16,909 --> 00:03:23,116
muisti, ehkä kovalevy 
ja niin edelleen. Toisin sanoen

35
00:03:23,116 --> 00:03:28,830
ongelma on tällaisen laajan luotetun ympäristön kanssa se, että myös

36
00:03:28,830 --> 00:03:35,521
haavoittuvuuksia voi olla 
kaikkialla. Ja myös haittaohjelmia piiloutuneena missä tahansa osassa.

37
00:03:35,521 --> 00:03:41,951
Enklaavissa ajamisen ideana on siis, esimerkiksi Intel SQX:ssä,

38
00:03:41,951 --> 00:03:48,406
yhdessä viimeisimmistä Intelin prosessoreista, 
että voit ottaa

39
00:03:48,406 --> 00:03:54,078
varsinaisen sovelluksen ohjelmistopinon osan suoritettavaksi enklaavin

40
00:03:54,078 --> 00:04:01,005
ulos koko koneen 
luotetusta ympäristöstä. Nyt sinun tarvitsee luottaa ainoastaan CPU:hun ja tietenkin

41
00:04:01,005 --> 00:04:05,148
omaan koodiisi, mutta itse 
käyttöjärjestelmään ei enää tarvitse luottaa. SGX

42
00:04:05,148 --> 00:04:10,049
esimerkiksi lupaa suojella toimintoa hyökkääjältä, joka on saanut 
haltuunsa pääkäyttäjän tiedot.

43
00:04:10,049 --> 00:04:14,694
Ja riippuen myös siitä, ketä vastaan olet puolustautumassa, esimerkiksi,

44
00:04:14,694 --> 00:04:20,864
haitallisten pilvipalveluiden toimittajilta. Joten ajattelepa, että voit ajaa applikaatiota pilvessä

45
00:04:20,864 --> 00:04:26,724
ja voit silti ajaa koodiasi luotettavasti laitteistotason 
eristyksellä.

46
00:04:26,724 --> 00:04:30,754
Ja sinulla on myös todisteet siitä. Eikä enää tarvitse luottaa edes

47
00:04:30,754 --> 00:04:40,503
pääkäyttäjään. Näin ollen ongelma on tietenkin, että hyökkäyspinta

48
00:04:40,503 --> 00:04:47,378
säilyy. Niinpä ainakin osa aiemmista hyökkäyksistä, joita 
esitellään tässäkin

49
00:04:47,378 --> 00:04:52,395
etäkongressissa tänä vuonna, on suuntautunut CPU:n

50
00:04:52,395 --> 00:04:58,589
mikroarkkitehtuuria kohtaan.Eli hyökätään 
periaatteessa laitetasolle. Teillä oli

51
00:04:58,589 --> 00:05:05,711
oli siis ennakointia, mikroarkkitehturaalista tiedon keruuta, haamuja, ladatun 
arvon injektointia jne.

52
00:05:05,711 --> 00:05:10,182
Mutta mihin on vähemmän kiinnitetty huomiota ja mihin kiinnitämme enemmän huomiota tässä

53
00:05:10,182 --> 00:05:17,028
huomiota tässä esittelyssä, on ohjelmistotaso 
enklaavin sisällä. Siellä on viitattu olevan

54
00:05:17,028 --> 00:05:22,360
luotettua koodia. Mutta nyt voidaankin katsoa tarkemmin,

55
00:05:22,360 --> 00:05:30,300
mitä enklaavin 
sisällä on. Nyt ohjelmistonäkökulmasta. Siis voiko

56
00:05:30,300 --> 00:05:34,304
hyökkääjä hyväksikäyttää mitään perinteistä 
ohjelmistohaavoittuvuutta enklaavissa?

57
00:05:35,520 --> 00:05:40,880
Kyllä, David. Tämä on mielenkiintoinen näkökulma, eikö totta? Puhutaanpa siis

58
00:05:40,880 --> 00:05:45,200
ohjelmistoista. Meidän täytyy ymmärtää mikä on ohjelmistoympäristö näille

59
00:05:45,200 --> 00:05:49,760
SGX enklaaveille ja 
luotetuille ajoympäristöille yleisesti. Ja tätä me selvitimme. Aloitimme

60
00:05:49,760 --> 00:05:53,760
analysoinnilla ja tässä muutamia 
kuvakaappauksia. Tämä on itse asiassa kasvava

61
00:05:53,760 --> 00:05:58,960
vapaan lähdekoodin ekosysteemi, monia ajo-ohjelmistoja, 
kirjastokäyttöjärjestelmiä ja ohjelmistokehitysympäristöjä.

62
00:05:58,960 --> 00:06:03,760
Ja ennen kuin menemme syvemmälle, haluan painottaa, että mikä on yhteinen tekijä

63
00:06:03,760 --> 00:06:09,760
joka kaikkia näitä yhdistää? 
Mikä on näiden ympäristöjen alkuperäinen ajatus ja idea?

64
00:06:09,760 --> 00:06:17,040
Mikä tahansa TEE, luotettu ajoympäristö,

65
00:06:17,040 --> 00:06:22,400
antaa käsityksen 
siitä, mikä on turvallinen suojapaikka vihamielisessä

66
00:06:22,400 --> 00:06:27,200
ympäristössä. Ja voit suorittaa toimintoja suojatussa osiossa 
kun

67
00:06:27,200 --> 00:06:33,440
ympäröivä maailma palaa. Minkä tahansa suojausmekanismin kohdalla, kuten jo aiemmin mainitsin,

68
00:06:33,440 --> 00:06:37,680
paholainen piilee 
yksityiskohdissa ja tyypillisesti portilla, eikö totta? Miten siis välität tietoa

69
00:06:37,680 --> 00:06:42,880
tämän epäluotettavan maailman joka palaa, ja enklaavissa olevan turvapaikan välillä?

70
00:06:42,880 --> 00:06:48,480
Ja 
intuitio kertoo, että että tarvitset jonkinlaisen välillä olevan ohjelmistokerroksen,

71
00:06:48,480 --> 00:06:53,040
jota kutsumme suojaustasoksi.
Se tekee tavallaan turvallisen

72
00:06:53,040 --> 00:06:57,760
sillan liikkua ympäristöstä toiseen. Ja siitä

73
00:06:57,760 --> 00:07:03,680
olemme kiinnostuneita. Nähdäksemme, millaisia tarkistuksia siellä tarvitaan.

74
00:07:03,680 --> 00:07:07,680
Sinulla on melko kaunis kuva asiasta, toisaalla hedelmällinen enklaavi ja

75
00:07:07,680 --> 00:07:13,680
toisaalla vihamielinen aavikko. Ja tähän 
tehdään turvallinen silta väliin. Ja mistä

76
00:07:13,680 --> 00:07:19,520
olemme kiinnostuneita, kun jokin menee vikaan? Mitä jos sinun siltasi onkin viallinen?

77
00:07:19,520 --> 00:07:25,600
Vastataksemme kysymykseen, katsotaan sitä välissä olevaa laatikkoa ja kysytään,

78
00:07:25,600 --> 00:07:30,400
millaista ylläpitoa ja millaisia tarkistuksia täytyy olla jotta edestakainen

79
00:07:30,400 --> 00:07:35,360
liikenne on mahdollista?
Ja yksi

80
00:07:35,360 --> 00:07:38,960
pääasiallisista tuloksistamme, joita olemme saavuttaneet tämän tutkimuksen kahtena viimeisenä vuotena, on mielestäni

81
00:07:38,960 --> 00:07:45,920
että tuo välilaatikko voidaan jakaa kahteen alemman tason kerrokseen.

82
00:07:45,920 --> 00:07:51,440
Näistä ensimmäinen on ABI, sovelluksen binäärirajapinta, hyvin alhainen CPUn tila. Ja

83
00:07:51,440 --> 00:07:54,640
toinen on mitä kutsumme APIksi, 
sovelluksen ohjelmointirajapinta.

84
00:07:54,640 --> 00:07:58,160
Tuo tila tai vaiheet on jo nähtävissä ohjelmointikielissä. Kuten

85
00:07:58,160 --> 00:08:02,400
esittelyssä mainittiin, me tavallaan ohjaamme teidät
läpi molempiin tasoihin asiaankuuluvien

86
00:08:02,400 --> 00:08:06,080
haavoittuvuuksien avulla, jotta ymmärrettäisiin mitä tämä tarkoittaa.

87
00:08:06,080 --> 00:08:11,760
Ensiksi Fritz ohjaa teidät mielenkiintoiseen ABI-tason alempaan toimintakenttään.

88
00:08:11,760 --> 00:08:15,440
Kyllä vaan. Ja kuten Jo jo mainitsitkin,

89
00:08:15,440 --> 00:08:21,840
se on CPUn tila ja sovelluksen binäärirajapinta. Mutta katsotaanpa

90
00:08:21,840 --> 00:08:27,200
hiukan mistä puhutaan. Periaatteessa se tarkoittaa sitä, että hyökkääjä

91
00:08:27,200 --> 00:08:39,348
hallitsee CPUn rekistereiden sisältöä....Jokaisella enklaavin sisään- ja ulostulolla

92
00:08:39,348 --> 00:08:46,480
täytyy suorittaa tehtäviä. Eli enklaavilla ja

93
00:08:46,480 --> 00:08:56,560
luotetulla ajoympäristöllä
on tietty CPU vaihe ja kääntäjä voi

94
00:08:56,560 --> 00:09:03,360
työskennellä niiden kutsujen kanssa, joita se odottaa. Nämä ovat siis avainosia.

95
00:09:03,360 --> 00:09:09,120
Meidän täytyy alustaa CPU rekisterit enklaaviin saapuessamme ja

96
00:09:09,120 --> 00:09:15,520
siivota ne poistuessamme. emme voi siis olettaa mitään

97
00:09:15,520 --> 00:09:20,960
hyökkääjän meille antamaa annetuksi. Meidän täytyy alustaa se joksikin kunnolliseksi ja käytettäväksi.

98
00:09:20,960 --> 00:09:30,320
Tutkimme useita TEE ajoympäristöjä ja löysimme paljon

99
00:09:30,320 --> 00:09:37,840
haavoittuvuuksia tältä ABI kerrokselta. Ja yksi tämän tutkimuksen
pääoivalluksista onkin se

100
00:09:37,840 --> 00:09:45,120
että monet näistä haavoittuvuuksista sijoittuu monimutkaisien ohjesarjojen prosessoreihin,

101
00:09:45,120 --> 00:09:51,760
siis CISC ja SGT TEE:issä. Tutkimme myös joitain

102
00:09:51,760 --> 00:09:57,840
RISC prosessoreita, ja vaikka ei pidä yleistää, niin on heti huomattavissa,

103
00:09:57,840 --> 00:10:06,000
että monimutkaisella x86 ABIlla on huomattavasti suurempi

104
00:10:06,000 --> 00:10:13,760
hyökkäyspinta-ala kuin yksinkertaisemmissa 
RISC arkkitehtuureissa. Katsotaanpa yhtä esimerkkiä tästä

105
00:10:13,760 --> 00:10:20,080
monimutkaisesta arkkitehtuurista.
Esimerkiksi x86:ssa merkkijono ohjeistus,

106
00:10:20,080 --> 00:10:26,800
jota säätelevät suuntaliput. X86:ssa on erityinen ohjeistus, joka

107
00:10:26,800 --> 00:10:33,200
periaatteessa mahdollistaa striimatut muistitoiminnot. Jos bufferiin

108
00:10:33,200 --> 00:10:40,960
tehdään muistin käsittelyyn toimintosarja, se käännetään merkkijonon toiminto-ohjeeksi.

109
00:10:40,960 --> 00:10:50,720
Merkkijono siis luetaan vasemmalta oikealle ja ylikirjoitetaan

110
00:10:50,720 --> 00:10:56,880
muistin käsittelysarjan toiminnolla. Mutta tuo lippu mahdollistaa myös käsittelyn päinvastoin,

111
00:10:56,880 --> 00:11:03,200
takaperin. Ei ajatella sitä miksi tämä oli hyvä ajatus tai mihin sitä

112
00:11:03,200 --> 00:11:08,720
tarvitaan. Mutta varmasti on siis mahdollisuus kääntää lippu toiseen asentoon ja lukea

113
00:11:08,720 --> 00:11:16,000
bufferin sisältö takaperin. Ja mitä me 
huomasimme: System-V ABIn mukaan

114
00:11:16,000 --> 00:11:21,120
tämä lippu täytyy olla asettamatta tai olla asetettu eteenpäin(vasemmalta oikealle).

115
00:11:21,120 --> 00:11:26,880
Ja kääntäjä olettaa tämän olevan näin. Katsotaanpa kuinka tämä tapahtuu

116
00:11:26,880 --> 00:11:33,840
enklaavissa. Jos ajamme tämän enklaavin sisällä, luotetussa ympäristössä

117
00:11:33,840 --> 00:11:39,680
normaalilla syötteellä normaalilla

118
00:11:39,680 --> 00:11:45,040
normaalilla lipulla, voimme nähdä, että ajo

119
00:11:45,040 --> 00:11:51,680
tapahtuu aivan oletetusti oikein päin. Jos hyökkääjä kuitenkin pääsee

120
00:11:51,680 --> 00:11:58,880
ja muuttaa lippuasetuksen toiseksi,

121
00:11:58,880 --> 00:12:05,840
ja pointerin kohdasta riippuen näemme ajon nyt menevän takaisinpäin luennassa.

122
00:12:05,840 --> 00:12:10,640
Siinä on ongelma. ja sitä emme selvästikään

123
00:12:10,640 --> 00:12:16,193
halua tapahtuvan luotetussa sovelluksessamme, koska

124
00:12:16,193 --> 00:12:22,880
koska kuten voitte kuvitella, 
se mahdollistaa niiden avainten ylikirjoittamisen,

125
00:12:22,880 --> 00:12:27,280
jotka ovat muistipaikassa, jossa voit lukea takaperin.

126
00:12:27,280 --> 00:12:32,960
Se mahdollistaa tiedon ulosluvun eikä se ole hyödyllistä. Kun saimme tämän raportoitua, se

127
00:12:32,960 --> 00:12:38,960
johti CVE:n syntymiseen korkealla score-arvolla, kuten näette seuraavalla dialla.

128
00:12:38,960 --> 00:12:46,800
Ja se on vain yksi instanssi. Täytyyhän tässä ajatella nyt

129
00:12:46,800 --> 00:12:54,400
kaikkia lippuasetuksia joita täytyy ylläpitää ja tarkistaa. Mutta, tietenkin

130
00:12:54,400 --> 00:13:02,960
on aina vielä jotain muutakin, eikö totta?
Huomasimme myös,

131
00:13:02,960 --> 00:13:07,440
että FPU:ssa (matemaattisten toimintojen osaprosessointi) on paljon muita rekistereitä ja paljon 
muita

132
00:13:07,440 --> 00:13:17,040
haavoittuvuuksia hyväksikäytettävänä. Enkä mene nyt yksityiskohtiin. Mutta tähän nyt

133
00:13:17,040 --> 00:13:25,704
vielä lisäksi, on olemassa 
vanhempi x86 ja ja uudempi SSE

134
00:13:25,704 --> 00:13:31,920
jotka suorittavat liukulukulaskentaa.
Eli on olemassa FPU ohjaussana ja MXCSR

135
00:13:31,920 --> 00:13:39,849
rekisteri näitä uudempia ohjeita varten. Ja tämä x86 on vanhempi, mutta sitä yhä käytetään

136
00:13:39,849 --> 00:13:45,680
esim. pitkien double muuttujien laskennassa. Eli ikä ei

137
00:13:45,680 --> 00:13:49,120
tässä kohtaa ole määrittelevää, koska niin vanha kuin uusikin on tässä tapauksessa yhä ajankohtaisia.

138
00:13:49,120 --> 00:13:58,160
X86 ja x87 ovat yhä olemassa ja se että voitaisiin sanoa että vanhat muinaiset jotka ovat

139
00:13:58,160 --> 00:14:03,280
vanhentuneita, ovatkin yhä 
käytössä ja siten huomioitava. Jos katsotaan

140
00:14:03,280 --> 00:14:09,200
System-V ABIa, huomasimme että nämä ohjausbitit ovat kutsujatallenteisia. 
Niitä siis

141
00:14:09,200 --> 00:14:13,680
säilytetään läpi funktiokutsujen.
Ja ideanahan on, mitä pidetään jossain määrin saavutuksena,

142
00:14:13,680 --> 00:14:22,400
että nämä ovat globaaleja tiloja, niitä välitetään

143
00:14:22,400 --> 00:14:27,680
koko sovellukselle. Yksi sovellus voi siis asettaa arvon

144
00:14:27,680 --> 00:14:35,280
ja se pysyy läpi niiden käyttöajan.
Mutta ongelma on, kuten näette

145
00:14:35,280 --> 00:14:39,760
on että sovelluksemme tai enklaavimme on periaatteessa yksi sovelluskokonaisuus, emmekä todellakaan halua

146
00:14:39,760 --> 00:14:44,480
hyökkääjän ottavan haltuunsa luotettua sovellustamme, eikö totta?

147
00:14:44,480 --> 00:14:52,502
Mitä siis tapahtuu jos FPU asetukset säilytetään eri kutsujen ajan?

148
00:14:52,502 --> 00:14:57,760
Sanotaanko että normaalikäyttäjälle, teemme laskentaa enklaavissa. Kuten

149
00:14:57,760 --> 00:15:03,280
2.1 kertaa 3.4 on 7.14, mikä on tyyppinä pitkä double.

150
00:15:03,280 --> 00:15:09,680
Tämä on OK? Mutta mitä tapahtuu jos hyökkääjä saapuu enklaaviin

151
00:15:09,680 --> 00:15:15,680
mukanaan saastutettuja määritelmiä FPU:lle? Saamme vääristyneitä

152
00:15:15,680 --> 00:15:21,520
tuloksia ja huonommalla tarkkuudella.

153
00:15:21,520 --> 00:15:26,400
Itse asiassa tässä se pyöristää alaspäin, aina kun

154
00:15:26,400 --> 00:15:31,280
tulos ylittää tarkkuuden. Ja sitähän emme halua? Tämä on jotain,

155
00:15:31,280 --> 00:15:38,240
missä kehittäjä odottaa tiettyä tarkkuutta tai pitkän doublen tarkkuutta,

156
00:15:38,240 --> 00:15:43,840
mutta hyökkääjä itse asiassa
supistaa tulosta ja sen tarkkuutta.

157
00:15:43,840 --> 00:15:49,760
Raportoimme tästä ja itse asiassa löysimme tämän aiheen myös Microsoft OpenEnclavesta. Siksi

158
00:15:49,760 --> 00:15:55,600
tätä ei ole merkitty hyväksikäytön mahdollisuudeksi. Mutta mitä huomioimme mielenkiintoisena kohtana on, että Intel

159
00:15:55,600 --> 00:16:01,200
SGX SDK, joka oli haavoittuvainen, korjasi tämän xrstore
ohjeella.

160
00:16:01,200 --> 00:16:10,400
Tämä säilyttää täysin tilan tiettynä arvona, kun taas OpenEnclave

161
00:16:10,400 --> 00:16:16,320
säilytti vain tietyn rekisteriarvon, joka oli kohteena, ldmxcst ohjeessa.

162
00:16:16,320 --> 00:16:19,600
Ohitetaanpa muutama dia tässä vaiheessa, koska haluan

163
00:16:19,600 --> 00:16:27,120
painottaa, että tämä ei ollut tarpeeksi.
Huomiomme mukaan, vaikka tämä tietty rekisteri säilytettiin,

164
00:16:27,120 --> 00:16:32,640
on muita rekistereitä,

165
00:16:32,640 --> 00:16:40,000
joita voi merkitä käytössä oleviksi
ennen enklaaviin saapumista, ja johon hyökkääjä voi

166
00:16:40,000 --> 00:16:45,600
muuttaa laskentatuloksen ei-numeraaliseksi. Tämä on hiljaista,

167
00:16:45,600 --> 00:16:50,080
eikä siis ohjelmointikieliriippuvaista, eikä kehittäjäriippuvaista. Tämä on

168
00:16:50,080 --> 00:16:55,840
hiljainen ABI asia, että laskenta ei ole ainoastaan numeroita.

169
00:16:55,840 --> 00:17:03,600
Raportoimme myös tämän. Ja nyt, onneksi, kaikki enklaaviympäristöt käyttävät tätä täyttä xrstor ohjetta.

170
00:17:03,600 --> 00:17:09,600
säilyttääkseen tämän laajennetun tilan. Siihen vaadittiin kaksi CVE:tä, mutta nyt

171
00:17:09,600 --> 00:17:15,760
ne suorittavat täyden hallinnan. En halua mennä nyt tutkimustemme ytimeen, vaan

172
00:17:15,760 --> 00:17:21,280
haluan nyt osoittaa näiden tutkimuksiemme tarkoituksen.

173
00:17:21,280 --> 00:17:29,440
Tutkimme näitä tapahtumia ja halusimme selvittää,

174
00:17:29,440 --> 00:17:36,800
ovatko ne vain vaikeita vaiko huonoja toteutuksia. Huomasimmekin, 
että

175
00:17:36,800 --> 00:17:41,680
ylivuotoja voidaan käyttää sivukanavana salaisuuksien päättelemiseen. Esimerkiksi,

176
00:17:41,680 --> 00:17:49,120
hyökkääjä voisi käyttää 
rekisteriä poikkeusten paljastamiseen jotta

177
00:17:49,120 --> 00:17:58,400
sitten enklaavin sisällä voitaisiin laukaista syöteriippuvaisesti kerrontaa.

178
00:17:58,400 --> 00:18:03,040
Lisäksi havaitsimme, että näiden sivukanavien kautta voidaan

179
00:18:03,040 --> 00:18:11,920
käyttää syötetilan binäärietsintään.

180
00:18:11,920 --> 00:18:16,880
Ja me voimme 
palauttaa tämän moninkertaistamisen määriteltyihin

181
00:18:16,880 --> 00:18:23,920
määrään vaiheita. Jos meillä on vain yksi maski, jonka käännämme voimme

182
00:18:23,920 --> 00:18:31,760
itse asiassa palauttaa toiminnon määriteltyihin vaiheisiin.

183
00:18:31,760 --> 00:18:36,560
Ja jotta tietäisimme, voimme tehdä myös enemmän. Voimme suorittaa myös koneoppimista

184
00:18:36,560 --> 00:18:44,080
enklaavissa.
Jo mainitsikin, että sitä voidaan tehdä TEEn sisällä, pilvessä. Ja

185
00:18:44,080 --> 00:18:47,760
se on koneoppimisessa mukavaa, eikö totta? Tehdäänpä hiukan käsinkirjoitetun luvun

186
00:18:47,760 --> 00:18:55,200
tunnistamista. Jos ajattelemme mallia, jossa toinen

187
00:18:55,200 --> 00:19:00,560
käyttäjä käyttää 
koneoppimismallia

188
00:19:00,560 --> 00:19:05,520
ja toinen käyttää enklaavia.

189
00:19:05,520 --> 00:19:10,960
Kaikki on turvallista, mutta huomasimme, että voimme saastuttaa näitä FPU

190
00:19:10,960 --> 00:19:18,320
rekistereitä ja näin alentaa 
koneoppimisen suorituskykyöä

191
00:19:18,320 --> 00:19:24,160
siten, että vain 8 prosenttia merkeistä tulkitaan oikein. Ja

192
00:19:24,160 --> 00:19:31,600
kaikki luvut olivat itse asiassa tuloksissa samoja,

193
00:19:31,600 --> 00:19:37,520
joten tämä koneoppiminen on tässä kohtaa hyödytöntä, eikö vain? Lisäksi voimme

194
00:19:37,520 --> 00:19:42,320
hyökätä kuvamuutoksia sekoittamalla, pienien kuvamuutosten ja sekoitettujen kuvien

195
00:19:42,320 --> 00:19:48,720
välillä. Tämä, jotta nähtäisiin, että on pieni mutta monimutkainen asia

196
00:19:48,720 --> 00:19:56,480
ja ilmaisee että kaikki voi mennä pieleen nopeasti ABI tasolla, jos siellä puuhailee.

197
00:19:56,480 --> 00:20:02,560
Tässä on kyse siis CPU tiloista. Nyt voidaankin puhua lisää

198
00:20:02,560 --> 00:20:06,400
sovellusten ohjelmointi rajapinnasta, joka onkin 
hiukan mukavampi

199
00:20:06,400 --> 00:20:09,440
aihe olettaisin.
Joo, otetaan vaan, kiitos

200
00:20:09,440 --> 00:20:14,160
Otetaanpa tähän melko yksinkertainen esimerkki.

201
00:20:14,160 --> 00:20:18,560
Oletetaan, että lataamme standardin unix binäärin enklaaviin, ja siellä on toiminnot sitä varten,

202
00:20:18,560 --> 00:20:24,960
vaikkapa graphene. 
Ja mitä haluan esittää tällä esimerkillä;

203
00:20:24,960 --> 00:20:29,680
On hyvin tärkeää tarkistaa, mistä osoittimet ovat lähtöisin. Koska

204
00:20:29,680 --> 00:20:34,686
enklaavi tavallaan osittaa muistin luotettuun enklaaviin ja ei-luotettuun muistiin,

205
00:20:34,686 --> 00:20:40,800
ne ovat erillisissä muistialueissa. Ongelma tässä on seuraava; Oletetaan että

206
00:20:40,800 --> 00:20:47,120
meillä on binäärin kaiutus, joka ainoastaan tuo näytölle input-arvon. Annamme toiminnolle argumenttinä
merkkijonon

207
00:20:47,120 --> 00:20:52,720
ja se normaalisti kaiuttaa sanotaanko "Hello, world", merkkijonon joka on ei-luotetussa

208
00:20:52,720 --> 00:20:58,480
muistissa. Kaikki sujuu kuten pitääkin,

209
00:20:58,480 --> 00:21:03,040
enklaavissa ajetaan komennot, se saa pointerin ulkopuoliseen muistiin ja printtaa merkkijonon.

210
00:21:03,040 --> 00:21:08,800
Ongelmana on kuitenkin se, että enklaavilla on pääsy

211
00:21:08,800 --> 00:21:15,520
myös omaan suojattuun muistiinsa. Jos hyökkääjä pääsee

212
00:21:15,520 --> 00:21:20,640
käsiksi pointeriin ja ohjaa sen jonkin suojattavan tiedon kohtaan,

213
00:21:20,640 --> 00:21:25,200
toiminto printtaa tiedon ulos, eikö niin? Eli äkkiä tämä onkin muuttunut muistin

214
00:21:25,200 --> 00:21:32,080
sulku haavoittuvuudeksi. Ja se nähdään tässä

215
00:21:32,080 --> 00:21:35,840
tapahtumassa mainitsemassani graphene ympäristössä. Meillä on siis

216
00:21:35,840 --> 00:21:40,640
yksinkertainen hello world -merkkijono ja sitä käsitellään parin argumentin avulla.

217
00:21:40,640 --> 00:21:45,440
Ja nyt, muutamme enklaavin ulkopuolella pointeria

218
00:21:45,440 --> 00:21:50,080
enklaavin muistissa. Seurauksena se printtaa halutun

219
00:21:50,080 --> 00:21:55,120
sijasta enklaavin 
muistissa sijaitsevan suojatun tiedon.

220
00:21:55,120 --> 00:22:00,960
suojatun tiedon. Tämän tyyppiset haavoittuvuudet

221
00:22:00,960 --> 00:22:05,600
ovat melko tunnettuja kernelien tutkinnasta ja muistakin yhteyksistä. Niitä

222
00:22:05,600 --> 00:22:11,600
kutsutaan niemllä confused deputy ( hämmentynyt apulaissheriffi). Sheriffillä on ase lukemiseen, 
mutta ei

223
00:22:11,600 --> 00:22:17,280
tiedäkään ongelman sattuessa mitä tehdä,

224
00:22:17,280 --> 00:22:22,000
kun ei alun perin tarkistanut kenelle muistipaikka kuuluu tai kuka sitä hallitsee.

225
00:22:22,000 --> 00:22:27,600
Tämä haavoittuvuus tuntuisi olevan helposti ratkaistavissa. Yksinkertaisesti

226
00:22:27,600 --> 00:22:31,680
tarkistetaan koko ajan mitä osoitin tulee. Mutta kuten sanottu,

227
00:22:31,680 --> 00:22:37,920
se ei aina ole helppoa. Kyllä David, on melko 
tarkkanäköistä,

228
00:22:37,920 --> 00:22:41,840
jos sanoo että meidän tulisi tarkistaa kaikki osoittimet. Niinpä me teimmekin.Tarkistimme kaikki

229
00:22:41,840 --> 00:22:46,320
pointereihin liittyvät tarkistukset ja huomasimme että Endolla on mielenkiintoinen tapa

230
00:22:46,320 --> 00:22:49,760
tarkistaa nämä kaikki. Toki, koodi on korkealaatuista. He tarkistivat

231
00:22:49,760 --> 00:22:53,360
kaikki pointerit, mutta asioiden eteen on tehtävä jotain erityistä. Puhumme nyt

232
00:22:53,360 --> 00:22:57,840
C ohjelmointikielestä. Käsittelyä ei siis erityisesti päätetä.

233
00:22:57,840 --> 00:23:02,880
Ne loppuvat uuteen tavuun ja funktiota voidaan käyttää samalla kun taistellaan

234
00:23:02,880 --> 00:23:05,920
tiedon pituuden kanssa. Ja miten tarkistus tehdään, kun tieto

235
00:23:05,920 --> 00:23:10,880
on täysin muistialueen ulkopuolella?
Ensimmäinen askel on käsitellä pituus,

236
00:23:10,880 --> 00:23:15,600
se on 10, ja sitten tarkistetaan alkaako ja loppuuko tietoalue

237
00:23:15,600 --> 00:23:19,280
kokonaan kohteen ulkopuolella. Kuulostaa paikkansapitävältä. Sitten päästetään

238
00:23:19,280 --> 00:23:23,760
höyryä. Tuntuu toimivan hienosti. Kuinka tämä toimii,

239
00:23:23,760 --> 00:23:26,440
kun yhdistetään eri ajoympäristöt. Emmekä nyt ajattele sitä, että koko setup on enklaavin ulkopuolella,

240
00:23:26,440 --> 00:23:34,160
johon salattu merkkijono välitetään.
Ensimmäinen askel

241
00:23:34,160 --> 00:23:38,320
on enklaavin aloittama käsittely merkkijonon pituuden suhteen.

242
00:23:38,320 --> 00:23:42,960
Kuulostaa melko mehukkaalta, mutta 
onneksi kaikki

243
00:23:42,960 --> 00:23:46,800
menee hyvin, kun huomataan että koko toimintoa ei olisi pitänyt tehdäkään ja

244
00:23:46,800 --> 00:23:50,880
koko toiminto on itse asiassa enklaavin sisällä. Pyyntö siis hylätään

245
00:23:50,880 --> 00:23:56,080
merkkijonon suhteen. Eli OK. Mutta kuten jotkut teistä tietävät,

246
00:23:56,080 --> 00:24:00,160
tämä on mielenkiitoista, koska 
English kilpaili asiasta,

247
00:24:00,160 --> 00:24:04,080
mistä ei koskaan pitänyt.
Ja tuon kilpailun pituus määrittyy

248
00:24:04,080 --> 00:24:10,480
1-bittien määrästä tehtäväannossa. Eli meillä on tässä sivukanava, jossa English

249
00:24:10,480 --> 00:24:16,080
palauttaa aina arvon False. Mutta aika, joka

250
00:24:16,080 --> 00:24:21,600
tuon arvon määrittämiseen menee, riippuu 0-tavujen määrästä Arncliffe

251
00:24:21,600 --> 00:24:26,640
muistiblokissa. Sen me löysimme. Olimme innoissamme ja sanoimme sen olevan yksinkertainen aikaikkunaongelma.

252
00:24:26,640 --> 00:24:31,920
Tällä mennään, eli tuon teimme ja näette sen tässä graafissa,

253
00:24:31,920 --> 00:24:36,480
ja se osoittautui hankalammaksi kuin miltä näyttää. Sininen

254
00:24:36,480 --> 00:24:39,840
1 mittaisen merkkijonon ja tuo on 2-mittaisen merkkijonon. Mutta

255
00:24:39,840 --> 00:24:43,760
mitenkään ei voida graafista päätellä, koska siinä 6 prosessoria toimii

256
00:24:43,760 --> 00:24:47,920
kovalla vauhdilla ja että yksi lisäys on täysin

257
00:24:47,920 --> 00:24:52,560
hävinnyt kanavaan. Sitä ei pysty selvittämään mittamalla käsittelyaikaa.

258
00:24:52,560 --> 00:24:59,120
Tarvitaan siis jotain muuta. Meillähän on viisaita kirjoituksia

259
00:24:59,120 --> 00:25:03,920
kirjallisuudessa, esimerkiksi hyvin yleisistä hyökkäyksistä ASICeihin, joista myös Intel kirjoittaa.

260
00:25:03,920 --> 00:25:09,520
Voitte nähdä, mitkä muistiblokkien sivut ovat käytössä, kun

261
00:25:09,520 --> 00:25:14,080
English ajaa, koska hallitset käyttöjärjestelmää ja 
sivutusmekanismeja.

262
00:25:14,880 --> 00:25:19,680
Sitä siis yritimme tehdä ajatellen että se onkin mukava sivukanava.

263
00:25:19,680 --> 00:25:24,480
Raavimme päätämme katsoessamme yksinkertaista ja lyhyttä luuppia koodissa,

264
00:25:24,480 --> 00:25:29,040
ja lyhyttä merkkijonoa joka sopii kokonaisuudessaan yhdelle muistisivulle.

265
00:25:29,040 --> 00:25:33,920
Vaikka meillä on pääsy muistiin, se ei auta meitä tässä, koska

266
00:25:34,560 --> 00:25:39,440
koodi ja data mahtuvat molemmat samalla sivulle.

267
00:25:39,440 --> 00:25:44,320
Tämä on siis väliaikainen ratkaisu, se ei ole tarpeeksi tarkka.

268
00:25:44,320 --> 00:25:51,040
Eli paljon on käsiteltävää ja olemme toimineet mielenkiintoisessa

269
00:25:51,040 --> 00:25:55,120
ympäristössä. Se käyttää epäsuoria osoituksia ja sitä sanotaan isoksi askeleeksi. Se on siis

270
00:25:55,120 --> 00:26:01,280
täydellinen viitekehys esimerkiksi Hadoopissa. Ja mitä se itse asiallisesi mahdollistaa

271
00:26:01,280 --> 00:26:05,200
sinun tehdä, on ajaa enklaavia askel kerrallaan, nimestään huolimatta.
Se siis myös mahdollistaa

272
00:26:05,200 --> 00:26:09,040
hyökkääjän puuttumisen koodin ajoon jokaisen ohjeen tai käskyn välissä.

273
00:26:09,040 --> 00:26:12,640
Ja miten me sen esitämme, on hyvin teknistä. Meillä on Linuxin kernelin

274
00:26:12,640 --> 00:26:18,480
ajo pienen kirjastokäyttöjärjestelmän ympärillä, mutta se

275
00:26:18,480 --> 00:26:23,200
ei ole ihan asian ydin. Asia on siinä, että voimme pysäyttää enklaavin

276
00:26:23,200 --> 00:26:27,538
jokaisen komennon jälkeen ja rauhassa pohtia, mitä voisimme tehdä.

277
00:26:27,538 --> 00:26:33,720
Mitä me ite asiassa voimme tehdä, on ajaa ja seurata tätä lisäkoodia

278
00:26:33,720 --> 00:26:38,918
yksi kerrallaan ja jokaisen keskeytyksen jälkeen 
yksinkertaisesti tarkistaa,

279
00:26:38,918 --> 00:26:45,066
saavuttaako enklaavi merkkijonon sieltä mihin olemme sen osoittaneet.
Se on toinen

280
00:26:45,066 --> 00:26:50,683
tapa ajatella asiaa, että meillä on ajo enklaavissa ja se voidaan rikkoa

281
00:26:50,683 --> 00:26:56,998
osiin ja laskea osat.

282
00:26:56,998 --> 00:27:03,440
Päättäväistä ajoittamista. Tosin sanoen meillä on ennustaja joka kertoo

283
00:27:03,440 --> 00:27:08,824
missä 0-tavut sijaitsevat. En tiedä onko se käytännöllistä, itse asiassa on.
Osoittautuu

284
00:27:08,824 --> 00:27:12,737
olevan niin, että jotkut jotka ovat syntyneet hyökkääjiksi,

285
00:27:12,737 --> 00:27:17,760
tietävät jo, että on hyvä tietää, missä kohta 
muistia nollat ovat. Ja

286
00:27:17,760 --> 00:27:23,537
nyt osoitamme esimerkin, missä rikomme A-S:n ja Iowan, jotka ovat kiihdytyskovona

287
00:27:23,537 --> 00:27:29,000
yrityksen AI prosesseissa. Ja 
nämä toimivat ainoastaan rekistereissä.

288
00:27:29,000 --> 00:27:34,130
Juuri mainittiin, että tavallaan pidetään tuosta yksittäisestä osoituksesta muistiin,

289
00:27:34,130 --> 00:27:38,832
mutta heti on olemassa toinenkin 
temppu. Eli aina kun enklaavi on

290
00:27:38,832 --> 00:27:44,080
keskeytetty, se säilöö senhetkiset rekisterinsä ja ajan johonkin muistilokeroonsa kehyksenä,

291
00:27:44,080 --> 00:27:50,425
joten voimme keskeyttää ja verifioida sen tekevän oikein.

292
00:27:50,425 --> 00:27:56,840
Ja sitten voimme ajaa tämän 0-tavu ennustajan tässä

293
00:27:56,840 --> 00:28:02,722
SSA muistissa. Ja mitä löydämme; missä 0 on tai onko siellä nollia lainkaan.

294
00:28:02,722 --> 00:28:08,747
En kuitenkaan halua mennä tarkemmin siihen, jos vastaus 
on kyllä. Mutta mitä

295
00:28:08,747 --> 00:28:15,835
itse asiassa teemme, kun löydämme nollan viimeisestä vaiheesta

296
00:28:15,835 --> 00:28:21,850
ennen viimeistä lisäyskierrosta ja sitten huomaamme että nolla kaatuu ja muuttuu X:ksi

297
00:28:21,850 --> 00:28:27,520
tai avaintavuksi, ja saamme tulokseksi salattua tekstiä. Me kuitenkin tiedämme

298
00:28:27,520 --> 00:28:33,601
salatekstin tavun, ja voimme palata takaisin päin.

299
00:28:33,601 --> 00:28:39,763
salatekstin tavun, ja voimme palata takaisin päin.

300
00:28:39,763 --> 00:28:45,840
Tämä ketju toistetaan 16 kertaa, kunnes on löydetty jokainen 0,

301
00:28:45,840 --> 00:28:51,460
ja meillä on käsissämme koko avain.

302
00:28:51,460 --> 00:28:56,294
Ja ne jotka tietävät, jos on käsissä yksi avainkooste on käsissä myös koko avain.

303
00:28:56,294 --> 00:29:00,654
Jos siis saat alkuperäisen avaimen, voit ajaa takaperin. Kuulostaa

304
00:29:00,654 --> 00:29:05,988
monimutkaiselta, mutta se on hyvin nopea hyökkäys minkä voit seuratessa todeta.

305
00:29:05,988 --> 00:29:11,473
Tässä on siis esimerkki tämän hyökkäyksen tekemisestä, ja kuten huomasitte muutamassa sekunnissa

306
00:29:11,473 --> 00:29:16,342
ja noin 520 Asirin hyödyntämisellä, saamme koko KeIson.

307
00:29:16,342 --> 00:29:21,401
Se on melko vaikuttavaa. Yksi keskeisimmistä

308
00:29:21,401 --> 00:29:26,268
asioista on se, että muistiin ei itse asiassa laiteta mitään, mutta

309
00:29:26,268 --> 00:29:33,062
toiminnassa SGX:n kanssa voit manipuloida sitä.

310
00:29:33,062 --> 00:29:41,372
Haluankin tässä vaiheessa päättää tämän, olemme kuitenkin löytäneet useita muitakin haavoittuvuuksia.

311
00:29:41,372 --> 00:29:47,838
Sekä tutkimus- että tuotantokoodissa, kuten Intelin tai

312
00:29:47,838 --> 00:29:52,708
Microsoftin SDK:ssa.
Ja ne menevät läpi koko alueen käyttäen

313
00:29:52,708 --> 00:29:57,700
vieraita kykyjä, joita on nähty muuallakin tutkimuksessa.

314
00:29:57,700 --> 00:30:02,680
Mutta, on olemassa myös uudenlaisia mielenkiintoisia esittämiimme aspekteihin liittyviä haavoittuvuuksia.

315
00:30:02,680 --> 00:30:08,240
Oli myös ongelmia kaikkien kutsuvälitysten kohdalla,

316
00:30:08,240 --> 00:30:13,770
kun enklaavi kutsui ulkopuolellaan olevia osia.

317
00:30:13,770 --> 00:30:18,740
Kutsuja joita käytetään emuloimaan järjestelmäkutsuja ja niin edelleen.
Ja jos palautat

318
00:30:18,740 --> 00:30:24,839
tässä yhteydessä ollain tavalla väärän tuloksen, voidaan taas lipsahtaa rajojen ulkopuolelle. Ne myös

319
00:30:24,839 --> 00:30:30,697
olivat erittäin, erittäin laajalle levinneitä. Ja lopuksi löysimme jotain tapauksia

320
00:30:30,697 --> 00:30:36,115
liittyen paddingiin (kryptauksen toiminto). en taaskaan halua mennä yksityiskohtiin.

321
00:30:36,115 --> 00:30:40,880
Olemme todenneet tässä asiassa, että voimme tehdä vertauksia oikeaan maailmaan.

322
00:30:40,880 --> 00:30:47,105
On tärkeää pestä kätensä, eli on tärkeää huoltaa ja tiloittaa osoittimet

323
00:30:47,105 --> 00:30:54,213
ja niin edelleen. Se on eräänlainen 
poistumisviesti,

324
00:30:54,213 --> 00:30:58,585
jolla kääntää ja ottaa yhteys turvallisesti.

325
00:30:58,585 --> 00:31:03,445
Kyllä, kaikki kovo-ongelmat täytyy ratkaista, mutta koodin täytyy olla turvallista.

326
00:31:03,445 --> 00:31:09,674
Enklaavien tapauksessa se tarkoittaa kunnollisia APIa ja APIen huoltoa. Tämä on itse asiassa erittäin

327
00:31:09,674 --> 00:31:15,718
vaikea tehtävä, mielestäni

328
00:31:15,718 --> 00:31:21,066
hyökkäyspinta-ala on suuri, erityisesti älykkään X:n

329
00:31:21,066 --> 00:31:25,781
tapauksessa, missä voit keskeyttää jokaisen toimen ja niin edelleen. Mielestäni tutkimuksen

330
00:31:25,781 --> 00:31:31,888
näkökulmasta, tarvitaan siis enemmän. Näkökulmasta jatkat jos haluat,

331
00:31:31,888 --> 00:31:38,010
ehkä voimme oppia 
jotain käyttäjästä analogiaan johon viittasin.

332
00:31:38,010 --> 00:31:43,734
Luullakseni tätä tarvitaan, jotta ymmärretään mitä

333
00:31:43,734 --> 00:31:48,650
enklaavin pitäisi tehdä verrattuna siihen mitä colonelin pitäisi 
tehdä.

334
00:31:48,650 --> 00:31:54,239
Ne ovat kuitenkin tärkeitä eroavaisuuksia, jotka tulisi ottaa huomioon. Joten luulisin,

335
00:31:54,239 --> 00:31:59,670
kuten sanoit, kaikki koodimme 
on avointa lähdekoodia.

336
00:31:59,670 --> 00:32:07,016
Joten kaiken esitellyn voit löytää allaolevien Github -linkkien kautta

337
00:32:07,016 --> 00:32:15,077
ja tietenkin voitte esittää kysymyksiä tämän esityksen katsomisen jälkeen.
Eli kiitoksia paljon.

338
00:32:15,077 --> 00:32:21,680
No niin, olemme palanneet jälleen. Ja tässä kysymyksiä?

339
00:32:21,680 --> 00:32:28,200
Ei vielä kysymyksiä....Voitte siis laittaa kysymyksiä tulemaan... Suljenpa nyt tämän

340
00:32:28,200 --> 00:32:36,751
ja kysynkin nyt kysymyksiä teiltä. Miten päädyitte tähän aiheeseen ja miten tapasitte toisenne?

341
00:32:36,751 --> 00:32:43,484
No se onkin melko mielenkiintoista. Ajattelen sen olevan

342
00:32:43,484 --> 00:32:50,158
rakentuneen pitkällä aikavälillä vuosien saatossa.
Luulisin sen olevan tulosta

343
00:32:50,158 --> 00:32:56,691
alkuperäisten suunnitelmiemme haavoittuvuuksista, Aloitin itse asiassa väitöskirjassani perusteiden keräämiseksi.

344
00:32:56,691 --> 00:33:01,763
Emme itse asiassa nähneet koko kuvaa ennenkuin tapasimme

345
00:33:01,763 --> 00:33:06,774
Davidin ja hänen kollegfansa Birminghamista Lontooseen. 
Mukava konferenssi.

346
00:33:06,774 --> 00:33:11,326
Ja sitten aloimme tehdä yhteistyötä ja toimia

347
00:33:11,326 --> 00:33:14,955
systemaattisemmin. Aloitin tämän haavoittuvuuksien listaamisen

348
00:33:14,955 --> 00:33:19,880
ja sen jälkeen teimme Davidin kanssa systemaattisemman analysoinnin.

349
00:33:19,880 --> 00:33:26,362
Ja se oli se Pandoran lipas,

350
00:33:26,362 --> 00:33:32,003
samoja virheitä toistaen. Sitten Fitzhugh, joka liittyi seuraamme hiljattain

351
00:33:32,003 --> 00:33:36,237
Lontoossa, alkoi työskennellä kanssamme

352
00:33:36,237 --> 00:33:40,520
matalan tason Sebu ominaisuuksien kanssa. Ja se itsessään on jo Pandoran lipas.

353
00:33:40,520 --> 00:33:46,506
Sanoisin että erityisesti yksi opetus, kuten sanoimme, oli tuo tietty kuutonen, joka on erityisen monimutkainen.

354
00:33:46,506 --> 00:33:51,233
Ja tuota kaikkea kompleksisuutta voidaan hyväksikäyttää, erityisesti

355
00:33:51,233 --> 00:33:55,904
biodiversiteettiä. Se on kuin osa moniosaisuudesta,

356
00:33:55,904 --> 00:34:01,831
missä avaat laatikon ja saat vastaukseksi yhä lisää kysymyksiä.

357
00:34:01,831 --> 00:34:08,731
On mielestäni reilua sanoa, että tämä tutkimus ei ole

358
00:34:08,731 --> 00:34:13,573
lopullinen vastaus aiheeseen, mutta se on yritys löytää järjestelmällinen tapa

359
00:34:13,573 --> 00:34:19,068
tarkastella loputtomia perusteita.

360
00:34:19,068 --> 00:34:26,034
Netin kautta on tullut kysymys. Onko muita olosuhteita missä

361
00:34:26,034 --> 00:34:33,188
Mianus kirjoittaa rekistereihin, kuin juuri SGX?

362
00:34:33,188 --> 00:34:44,160
Täytyy sanoa, etten myöskään ymmärrä kysymystä, mutta kokisin sen niin

363
00:34:44,160 --> 00:34:49,280
että onko tulos taktinen häviö? Vankila riippuu siitä, että kun on muistin huollon

364
00:34:50,000 --> 00:34:54,720
yhteydessä meitä syytetään sisällön muistiin

365
00:34:54,720 --> 00:34:58,960
pakottamisesta.

366
00:35:00,000 --> 00:35:05,040
Eli se on ehdottomasti hmmm.

367
00:35:05,040 --> 00:35:08,960
Sanoisin kuitenkin että yksi opetuksista viimeisen viiden tutkimusvuoden aikana on,

368
00:35:08,960 --> 00:35:13,200
että usein nämä asiat 
yleistyvät kuutosen jälkeen
ja ainakin yleisesti,

369
00:35:13,200 --> 00:35:18,880
oivallus SEBUsta, että oikeellisuus muistin käsittelyssä saavutetaan tavalla tai toisella, 
ennemmin tai myöhemmin.

370
00:35:18,880 --> 00:35:23,040
Mielestäni tuo pätee järjestelmien luomisessa, että jos jotenkin voi pakottaa

371
00:35:23,040 --> 00:35:26,080
käyttöjärjestelmän kompleksisuuten 
sovellusten osalta,

372
00:35:27,200 --> 00:35:32,160
rekistereitten käyttö muistissa on pakollista. Jos teillä olisi jotain samankaltaista mitä

373
00:35:32,160 --> 00:35:37,200
meillä on käyttöjärjestelmässä, Colonelissä, teillä olisi 
potentiaalinen hyväksikäytön paikka.

374
00:35:37,760 --> 00:35:43,680
Mutta ehkä David haluaa jotain käyttöjärjestelmistä myös.

375
00:35:43,680 --> 00:35:48,240
Ei en oikeastaan.
Ajattelisin, että eräs asia mikä helpottaa SGX:n

376
00:35:48,240 --> 00:35:53,200
kanssa on tiukka kontrolli, kuten mainitsit, keskeytysten ja muun 
kanssa,

377
00:35:53,200 --> 00:35:58,080
kun olette matkallanne enklaavin ulkopuolella. Voitte siis askeltaa käytännössä koko

378
00:35:58,080 --> 00:36:03,280
enklaavin, kuten keskeyttämällä koko käyttöjärjestelmän.

379
00:36:03,280 --> 00:36:08,320
Tarkoin toistettuna 
oikeassa kohdassa joku toinen prosessi

380
00:36:09,120 --> 00:36:13,760
on taipuvainen olemaan vaikeampi suunnittelultaan. Mutta kontekstissa, jossa

381
00:36:13,760 --> 00:36:19,360
meidän täytyy tallentaa jotain turvaan, se on

382
00:36:19,360 --> 00:36:25,840
rekisterit joista se päätyy muistiin, 
joissain tilanteissa

383
00:36:25,840 --> 00:36:34,480
vähemmän kontrolloidusti kuin esim. Asgeirssonin tapauksessa. On siis olemassa kysymys, entä muut CPU -arkkitehtuurit

384
00:36:34,480 --> 00:36:41,840
kuin Intel, testasitteko niitä? Ehkä voin mennä hiukan tähän, mielenkiintoista.

385
00:36:41,840 --> 00:36:48,160
Intelhän on suurin, sillä on suurin ohjelmistoalusta ja eniten ajossa olevia ympäristöjä.

386
00:36:48,160 --> 00:36:53,440
Sitähän me voisimme tutkia.
Mutta tietenkin on olemassa muutakin,

387
00:36:53,440 --> 00:37:01,040
kuten muutama vuosi sitten kehittämämme Sancho's.

388
00:37:01,040 --> 00:37:05,440
Ja tietenkin silläkin on 
samat aiheet. Eli aina tarvitaan

389
00:37:05,440 --> 00:37:14,880
ohjelmistokerros jonka täytyy päästä enklaaviin.
Luullakseni

390
00:37:14,880 --> 00:37:20,880
David aikaisemmassa työssään löysi ongelmakohtia TEE:sämme
Eli tämä ei ole ainoastaan

391
00:37:20,880 --> 00:37:27,120
Intel-sidonnaisten projektien sotkun paikka. Mutta mitä me

392
00:37:27,120 --> 00:37:34,000
varmasti huomasimme, on helpompaa ajatella kaikkia tapauksia yksinkertaisemmissa ympäristöissä

393
00:37:34,000 --> 00:37:38,080
kuin viitosessa ja sitä helpommissa, kuin kompleksisemmaassa kuutosessa.

394
00:37:39,360 --> 00:37:43,840
Joten nyt ei ole paljoa ympäristöjä vähemmille tempuille.

395
00:37:43,840 --> 00:37:48,880
Heillä on siis etu ja haitta olla ensimmäisiä laajasti

396
00:37:48,880 --> 00:37:56,000
levinneitä, mutta luulen että kun muutkin alkavat kasvaa

397
00:37:56,000 --> 00:38:00,960
ja yksinkertaisemmat arkkitehtuurit yleistyvät,näemme että

398
00:38:00,960 --> 00:38:05,649
on helpompi korjata väitettyjä ongelmia niissä. OK, mikä on

399
00:38:05,649 --> 00:38:18,966
järkevä vaihtoehto TEElle vai onko sitä.

400
00:38:18,966 --> 00:38:27,215
Meillä molemmilla on asiaan omat perspektiivimme, näin ajattelisin.

401
00:38:27,215 --> 00:38:31,842
Kysymyksen vakiintuessa, tarvitsemmeko

402
00:38:31,842 --> 00:38:34,992
vaihtoehtoja vai tarvitsemmeko systemaattisempia tapoja huoltaa

403
00:38:34,992 --> 00:38:39,212
Australians? Se on mielestäni osavastaus tähän, että meidän ei tarvitse

404
00:38:39,212 --> 00:38:43,240
heittää tätä hukkaan, vaikka sen kanssa on ongelmiakin.

405
00:38:43,240 --> 00:38:46,990
Voimme myös miettiä miten ratkaista nuo ongelmat. Mutta sen ulkopuolella meillä on jännittävää

406
00:38:46,990 --> 00:38:52,124
tutkimusta. OK, ehkä David myös haluaa sanoa hieman lisää esimerkiksi

407
00:38:52,124 --> 00:38:57,305
ominaisuuksista, mutta se ei välttämättä ole niin erilaista 
tähän verrattuna.

408
00:38:57,305 --> 00:39:00,864
Silloin kun on high tech tukea kuten Cherry

409
00:39:00,864 --> 00:39:04,646
Borjessonin tietokoneen osalla, joka itsesiallisesti yhdistää metadatan

410
00:39:04,646 --> 00:39:09,692
metadatapisteisiin, kuten tilaustarkistuksia

411
00:39:09,692 --> 00:39:14,837
silloin puhumiemme aiheiden saastutushyökkäyksiä voitaisiin saada

412
00:39:14,837 --> 00:39:20,651
kiinni ilman itse ilman tukea. Mutta se on hyvin korkean tason idea. Ehkä David

413
00:39:20,651 --> 00:39:26,080
jhaluaasanoa jotain. Kyllä, ajattelisin että vaihtoehtona TEE:lle,

414
00:39:26,080 --> 00:39:31,640
haluat osittaa järjestelmäsi, mikä on mielestäni hyvä ajatus. Jza

415
00:39:31,640 --> 00:39:37,523
Ja kaikki tekevät sitä nyt, miten online palveluita tehdään ja niin edelleen.

416
00:39:37,523 --> 00:39:44,276
Nämä ovat järjestelmiä jotka ovat yleistyneet

417
00:39:44,276 --> 00:39:48,976
matkapuhelimissa tai vaikkapa pankkikorttijärjestelmissä,

418
00:39:48,976 --> 00:39:52,729
jotka ovat suojattu ympäristö yksinkertaisille toimille. Mutta

419
00:39:52,729 --> 00:39:57,501
ongelmat alkavat, kun laitetaan paljon toiminnallisuuksia tähän ympäristöön.

420
00:39:57,501 --> 00:40:03,318
Kuten näimme, luotettu koodipohja 
tulee yhä monimutkaisemmaksi ja saadaan ympäristöstä perinteinen laatikko.

421
00:40:03,318 --> 00:40:08,059
On todellinen kysymys, tarvitaanko vaihtoehto vaiko

422
00:40:08,059 --> 00:40:11,794
parempi lähestymiskulma aiheeseen. Miten voitte, ositusohjelmistot? Ja kuten mainitsit

423
00:40:11,794 --> 00:40:16,406
on asioita joita voi hoitaa arkkitehtuurilla.

424
00:40:16,406 --> 00:40:21,386
Näin voidaan laajentaa arkkitehtuureita 
ominaisuuksilla

425
00:40:21,386 --> 00:40:25,955
ja sitten aloittaa komponenttien eristäminen.

426
00:40:25,955 --> 00:40:30,299
Esimerkiksi, ohjelmistoprojektissa, sanotaanko Web-serverilläsi, sinä eristät stackin tai jotain vastaavaa. Ja

427
00:40:30,299 --> 00:40:37,526
kiitokset katsojille salalisen salasanan huomaamisesta,
sehän tehdään vain näön tähden,

428
00:40:37,526 --> 00:40:45,854
antaaksemme ihmisille jotain katseltavaa.

429
00:40:45,854 --> 00:40:54,612
Mutta sehän ei ole perusteiltaan viallinen?
Tarkoitan että niitä on niin monia,

430
00:40:54,612 --> 00:41:02,261
ettet voi sanoa niiden olevan perusteiltaan viallinen, mutta

431
00:41:02,261 --> 00:41:08,342
erityisesti SGX:ää 
ajatellen, koska signaali käyttää mobiilikolikoita

432
00:41:08,342 --> 00:41:15,680
kryptovaluutta käyttää sitä, ja niin edelleen ja niin edelleen. Onko se perusteiltaan viallinen

433
00:41:15,680 --> 00:41:24,428
vai haluatko mieluummin sanoa niin? Sehän riippuu perusteiltaan kunnossa olevan 
määritelmästä.

434
00:41:24,428 --> 00:41:29,915
Menneisyydessä olemme työskennelleet myös

435
00:41:29,915 --> 00:41:35,107
asenteiden rikkomisen parissa, mutta ne on saatu korjattua ja on aika kaunis

436
00:41:35,107 --> 00:41:40,909
ja hyvin tutkittu kokonaisuus jolla on myös lyhytaikaisia vaikutuksia tuotantoon.

437
00:41:40,909 --> 00:41:45,924
Löydät siis haavoittuvuuden, toimittajan on tehtävä korjaus jota ei ole olemassa

438
00:41:45,924 --> 00:41:50,014
tai siihen tulee väliaikainen 
korjaus. Sitten myöhemmin

439
00:41:50,014 --> 00:41:54,432
tarvitaan uusia prosesseja jotta saataisiin lopullinen korjaus ongelmaan

440
00:41:54,432 --> 00:41:58,668
ja kuitenkin siihen 
saadaan taas

441
00:41:58,668 --> 00:42:04,655
väliaikaisia korjauksia. Jos esimerkiksi yhtiö kuten Signeul käyttää

442
00:42:04,655 --> 00:42:10,059
niitä, et saa oletuksena turvallisuutta. Mutta täytyy ajatella

443
00:42:10,059 --> 00:42:14,108
ohjelmistoja. niihin keskitytään tässä tapauksessa.
Täytyy ajatella

444
00:42:14,108 --> 00:42:20,394
myös laitteistoja, mikropaikkauksia ja prosessoreita joissa täytyy huolehtia kaikista

445
00:42:20,394 --> 00:42:26,470
tunnetuista haavoittuvuuksista. Ja silti täytyy aina kysyä, että entä

446
00:42:26,470 --> 00:42:30,824
ne mahdollisuudet joita emme vielä tunne, missään turvallisessa järjestelmässä.

447
00:42:30,824 --> 00:42:36,676
Ehkä David haluaa sanoa jotain viimeisimmästä työstään.

448
00:42:36,676 --> 00:42:42,504
Hiukan mielenkiintoista.
Ajattelenpa, että mikä tahansa lähtökohtasi

449
00:42:42,504 --> 00:42:48,083
tai minun vastaukseni tähän kysymykseen olisi, riippuu tietenkin 
uhkamallista.

450
00:42:48,083 --> 00:42:54,045
Jotkut käyttävät SGX:ää siirtääkseen luotetut asiat pilvipalvelun tuottajalle,

451
00:42:54,045 --> 00:42:59,511
kuten RSS tai Signaler. Siirretään 
siis kaikki nämä toiminnot

452
00:42:59,511 --> 00:43:04,655
jollekin pilvitoimittajalle enklaaviin. Tällöin minun ei tarvitse

453
00:43:04,655 --> 00:43:10,673
luottaa pilvitoimittajaan, koska myös fyysiseen turvallisuuteen on jotain.

454
00:43:10,673 --> 00:43:15,760
luottaa pilvitoimittajaan, koska myös fyysiseen turvallisuuteen on jotain. 
Vähän aikaa sitten paljastimme kuitenkin haavoittuvuuden,

455
00:43:15,760 --> 00:43:22,130
joka osoittaa, että jos sinulla on fyysinen pääsy SGX:ään,

456
00:43:22,130 --> 00:43:28,138
voit injektoida prosessorin pelaamalla voting rajapinnalla, joka on laitteistossa.

457
00:43:28,138 --> 00:43:33,155
Siinä todellakin nähtiin, että pari johtoa emolevyn väylältä

458
00:43:33,155 --> 00:43:38,442
jännitteen säätimeen. Saadaan aikaan jännitepiikki,

459
00:43:38,442 --> 00:43:43,824
kuten 
voitte tietääkin.

460
00:43:43,824 --> 00:43:48,680
Sillä tavalla voidaan kääntää bittejä enklaavissa

461
00:43:48,680 --> 00:43:54,589
ja näin tietenkin tehdä kaikenlaista

462
00:43:54,589 --> 00:43:59,612
pahuutta, kuten injektoida, 
jonka avulla taas voidaan saada avaimia, kaapata ohjaus, tai jotakin. Se siis riippuu

463
00:43:59,612 --> 00:44:04,802
uhkamallista. En sanoisi niin, että ASX on täysin turha. Sekin

464
00:44:04,802 --> 00:44:10,200
on parempi kuin ei mitään. Mutta 
ehdottomasti, et voi olla

465
00:44:10,200 --> 00:44:15,314
täysin turvassa jos jollain on fyysinen pääsy palvelimellesi.

466
00:44:15,314 --> 00:44:20,880
Nyt minun täytyy lopettaa keskustelu, pahus sentään. Ja kysyisin kaikki kysymykset

467
00:44:20,880 --> 00:44:26,100
jotka sain. Mutta hyvin lyhyt 
vastaus, kiitos. Mikä tuo juttu on tuon

468
00:44:26,100 --> 00:44:30,627
salasanan kanssa tuolla taustalla?
Minähän selitin sen, se on vaan puhdas vitsi.

469
00:44:30,627 --> 00:44:35,609
Sanon sen vielä kerran, koska jotkut näyttävät ottaneen sen vakavasti. 
Se on

470
00:44:35,609 --> 00:44:40,438
vain tilan täytteeksi.
Laitoin sen vaan sinne sen takia. Se ei muutoin olekaan kokonaan sieltä luettavissa, onneksi.

471
00:44:40,438 --> 00:44:46,234
Minun täytyy varmasti ottaa ja avata David Oswaldin kirja.

472
00:44:46,234 --> 00:45:00,100
Kiitokset hyvätä keskustelusta ja nyt siirrytäänkin seuraavaan

473
00:45:00,100 --> 00:45:03,840
esitykseen.

474
00:45:03,840 --> 00:45:34,000
[Translated by Kari Kananoja (ITKST56 course assignment at JYU.FI)] 2023