0:00:00.000,0:00:10.667
[Translated by Kari Kananoja (ITKST56 course assignment at JYU.FI)] Alkumusiikkia

0:00:12.235,0:00:17.520
Seuraavassa keskustelussamme on mukana Jo Van Bulk ja Fritz Adler [br]belgialaisesta Leuvenin

0:00:17.520,0:00:24.640
yliopistosta ja David Oswald, kyberturvallisuuden [br]professori Birminghamista.

0:00:24.640,0:00:29.840
He ovat täällä keskustelemassa luotetusta toiminto/ajoympäristöstä (TEE)[br](laitteen eristetty prosessorin osa, johon esim. laitteen käyttöjärjestelmällä ei ole pääsyä).

0:00:29.840,0:00:36.320
Tiedättekin varmasti Intelin ja vastaavien perusteella, että siihen eli luultavasti pitäisi luottaa lainkaan,

0:00:36.320,0:00:42.160
koska se on ohjelmoitua ja siinä on virheensä. Niinpä he puhuvatkin nyt

0:00:42.160,0:00:47.680
prosessorin enklaaviportteihin iskemisestä,[br]mikä on aina hyvä, järjestelmällisen haavoittuvuuden

0:00:47.680,0:00:52.080
arviointikohde TEEn suojauksessa. Olkaa hyvät ja jatkakaa.

0:00:52.080,0:00:58.690
Hei kaikille. Tervetuloa mukaan keskusteluun. Olen Jo, imec-DistriNet

0:00:58.690,0:01:02.640
tutkimusryhmän perustaja Leuvenin yliopistolla.[br]Ja tänään mukana on myös Fritz, myös Leuvenista

0:01:02.640,0:01:06.800
ja David Birminghamin yliopistosta. Meillä on tämä hyvin kiinnostava

0:01:06.800,0:01:11.440
aihe keskusteltavana, enklaaviportteihin iskeminen. Mutta ennen kuin syvennymme siihen,

0:01:11.440,0:01:16.400
uskon että suurin osa teistä [br]ei tiedä mitä ovat enklaavit, tai yleensä TEEt

0:01:16.400,0:01:23.520
Joten aloitankin tässä analogialla. Enklaavit ovat eräänlaisia

0:01:23.520,0:01:29.520
turvallisuuslinnakkeita prosessoreissa, CPUissa. [br]Se on siis kryptattu muistialue,

0:01:29.520,0:01:36.960
johon on pääsy vain TEEn sisäpuolelta. Mitä tiedämme

0:01:36.960,0:01:41.560
linnoitusten puolustautumisen ja niihin hyökkäysten historiasta, kun et

0:01:41.560,0:01:46.560
pääse linnoitukseen koska seinät ovat korkeita ja paksuja. parasta onkin suunnata porteille.

0:01:46.560,0:01:51.280
Se on linnoituksen heikoin kohta. Ja se on

0:01:51.280,0:01:57.440
tämän aiheemme idea. Se siis pätee myös enklaaveihin. Me olemme

0:01:57.440,0:02:01.520
iskeneet enklaavien portteihin, olemme hyökänneet syöte- ja tulosterajapintoihin.

0:02:01.520,0:02:07.600
Siis hyvin yksinkertainen idea, mutta dramaattiset vaikutukset, sanoisin.

0:02:07.600,0:02:14.640
Tämä on siis jonkinlainen päätelmä tutkimuksistamme. 40 rajapinnan

0:02:14.640,0:02:20.480
huoltoon liittyvää [br]haavoittuvuutta jotka löysimme kahdeksassa paljon käytetyssä openvapaan lähdekoodin

0:02:20.480,0:02:27.040
projektissa. Menemme tähän hiukan syvemmälle lopuissa dioissa.

0:02:27.040,0:02:32.400
On mukavaa sanoa, että [br]se on johtanut kahteen akateemiseen julkaisuun,

0:02:32.400,0:02:38.880
enemmän kuin 7 CVE-tietoon ja [br]kokonaisuudessaan melko hallittuun loppuun käsittelyyn ja

0:02:38.880,0:02:46.095
pitkiin käytön rajoituksiin. [br]OK, Meidän täytynee

0:02:46.095,0:02:55.197
keskustella miksi me yleensä tarvitsemme moisia enklaavi linnoituksia. [br]Jos mietitään

0:02:55.197,0:03:00.230
Jos mietitään perinteistä käyttöjärjestelmä-tai tietokonearkkitehtuuria, siinä on

0:03:00.230,0:03:06.131
käytössä [br]hyvin laaja luotettu toimintoperusta. Esimerkiksi, jos katselet tätä keskustelua esim. kannettavalta

0:03:06.131,0:03:12.265
luotat kerneliin, [br]luotat ehkä

0:03:12.265,0:03:16.909
virtuaalikoneeseen jos sinulla on koko ympäristö toteutettuna: CPU,

0:03:16.909,0:03:23.116
muisti, ehkä kovalevy [br]ja niin edelleen. Toisin sanoen

0:03:23.116,0:03:28.830
ongelma on tällaisen laajan luotetun ympäristön kanssa se, että myös

0:03:28.830,0:03:35.521
haavoittuvuuksia voi olla [br]kaikkialla. Ja myös haittaohjelmia piiloutuneena missä tahansa osassa.

0:03:35.521,0:03:41.951
Enklaavissa ajamisen ideana on siis, esimerkiksi Intel SQX:ssä,

0:03:41.951,0:03:48.406
yhdessä viimeisimmistä Intelin prosessoreista, [br]että voit ottaa

0:03:48.406,0:03:54.078
varsinaisen sovelluksen ohjelmistopinon osan suoritettavaksi enklaavin

0:03:54.078,0:04:01.005
ulos koko koneen [br]luotetusta ympäristöstä. Nyt sinun tarvitsee luottaa ainoastaan CPU:hun ja tietenkin

0:04:01.005,0:04:05.148
omaan koodiisi, mutta itse [br]käyttöjärjestelmään ei enää tarvitse luottaa. SGX

0:04:05.148,0:04:10.049
esimerkiksi lupaa suojella toimintoa hyökkääjältä, joka on saanut [br]haltuunsa pääkäyttäjän tiedot.

0:04:10.049,0:04:14.694
Ja riippuen myös siitä, ketä vastaan olet puolustautumassa, esimerkiksi,

0:04:14.694,0:04:20.864
haitallisten pilvipalveluiden toimittajilta. Joten ajattelepa, että voit ajaa applikaatiota pilvessä

0:04:20.864,0:04:26.724
ja voit silti ajaa koodiasi luotettavasti laitteistotason [br]eristyksellä.

0:04:26.724,0:04:30.754
Ja sinulla on myös todisteet siitä. Eikä enää tarvitse luottaa edes

0:04:30.754,0:04:40.503
pääkäyttäjään. Näin ollen ongelma on tietenkin, että hyökkäyspinta

0:04:40.503,0:04:47.378
säilyy. Niinpä ainakin osa aiemmista hyökkäyksistä, joita [br]esitellään tässäkin

0:04:47.378,0:04:52.395
etäkongressissa tänä vuonna, on suuntautunut CPU:n

0:04:52.395,0:04:58.589
mikroarkkitehtuuria kohtaan.Eli hyökätään [br]periaatteessa laitetasolle. Teillä oli

0:04:58.589,0:05:05.711
oli siis ennakointia, mikroarkkitehturaalista tiedon keruuta, haamuja, ladatun [br]arvon injektointia jne.

0:05:05.711,0:05:10.182
Mutta mihin on vähemmän kiinnitetty huomiota ja mihin kiinnitämme enemmän huomiota tässä

0:05:10.182,0:05:17.028
huomiota tässä esittelyssä, on ohjelmistotaso [br]enklaavin sisällä. Siellä on viitattu olevan

0:05:17.028,0:05:22.360
luotettua koodia. Mutta nyt voidaankin katsoa tarkemmin,

0:05:22.360,0:05:30.300
mitä enklaavin [br]sisällä on. Nyt ohjelmistonäkökulmasta. Siis voiko

0:05:30.300,0:05:34.304
hyökkääjä hyväksikäyttää mitään perinteistä [br]ohjelmistohaavoittuvuutta enklaavissa?

0:05:35.520,0:05:40.880
Kyllä, David. Tämä on mielenkiintoinen näkökulma, eikö totta? Puhutaanpa siis

0:05:40.880,0:05:45.200
ohjelmistoista. Meidän täytyy ymmärtää mikä on ohjelmistoympäristö näille

0:05:45.200,0:05:49.760
SGX enklaaveille ja [br]luotetuille ajoympäristöille yleisesti. Ja tätä me selvitimme. Aloitimme

0:05:49.760,0:05:53.760
analysoinnilla ja tässä muutamia [br]kuvakaappauksia. Tämä on itse asiassa kasvava

0:05:53.760,0:05:58.960
vapaan lähdekoodin ekosysteemi, monia ajo-ohjelmistoja, [br]kirjastokäyttöjärjestelmiä ja ohjelmistokehitysympäristöjä.

0:05:58.960,0:06:03.760
Ja ennen kuin menemme syvemmälle, haluan painottaa, että mikä on yhteinen tekijä

0:06:03.760,0:06:09.760
joka kaikkia näitä yhdistää? [br]Mikä on näiden ympäristöjen alkuperäinen ajatus ja idea?

0:06:09.760,0:06:17.040
Mikä tahansa TEE, luotettu ajoympäristö,

0:06:17.040,0:06:22.400
antaa käsityksen [br]siitä, mikä on turvallinen suojapaikka vihamielisessä

0:06:22.400,0:06:27.200
ympäristössä. Ja voit suorittaa toimintoja suojatussa osiossa [br]kun

0:06:27.200,0:06:33.440
ympäröivä maailma palaa. Minkä tahansa suojausmekanismin kohdalla, kuten jo aiemmin mainitsin,

0:06:33.440,0:06:37.680
paholainen piilee [br]yksityiskohdissa ja tyypillisesti portilla, eikö totta? Miten siis välität tietoa

0:06:37.680,0:06:42.880
tämän epäluotettavan maailman joka palaa, ja enklaavissa olevan turvapaikan välillä?

0:06:42.880,0:06:48.480
Ja [br]intuitio kertoo, että että tarvitset jonkinlaisen välillä olevan ohjelmistokerroksen,

0:06:48.480,0:06:53.040
jota kutsumme suojaustasoksi.[br]Se tekee tavallaan turvallisen

0:06:53.040,0:06:57.760
sillan liikkua ympäristöstä toiseen. Ja siitä

0:06:57.760,0:07:03.680
olemme kiinnostuneita. Nähdäksemme, millaisia tarkistuksia siellä tarvitaan.

0:07:03.680,0:07:07.680
Sinulla on melko kaunis kuva asiasta, toisaalla hedelmällinen enklaavi ja

0:07:07.680,0:07:13.680
toisaalla vihamielinen aavikko. Ja tähän [br]tehdään turvallinen silta väliin. Ja mistä

0:07:13.680,0:07:19.520
olemme kiinnostuneita, kun jokin menee vikaan? Mitä jos sinun siltasi onkin viallinen?

0:07:19.520,0:07:25.600
Vastataksemme kysymykseen, katsotaan sitä välissä olevaa laatikkoa ja kysytään,

0:07:25.600,0:07:30.400
millaista ylläpitoa ja millaisia tarkistuksia täytyy olla jotta edestakainen

0:07:30.400,0:07:35.360
liikenne on mahdollista?[br]Ja yksi

0:07:35.360,0:07:38.960
pääasiallisista tuloksistamme, joita olemme saavuttaneet tämän tutkimuksen kahtena viimeisenä vuotena, on mielestäni

0:07:38.960,0:07:45.920
että tuo välilaatikko voidaan jakaa kahteen alemman tason kerrokseen.

0:07:45.920,0:07:51.440
Näistä ensimmäinen on ABI, sovelluksen binäärirajapinta, hyvin alhainen CPUn tila. Ja

0:07:51.440,0:07:54.640
toinen on mitä kutsumme APIksi, [br]sovelluksen ohjelmointirajapinta.

0:07:54.640,0:07:58.160
Tuo tila tai vaiheet on jo nähtävissä ohjelmointikielissä. Kuten

0:07:58.160,0:08:02.400
esittelyssä mainittiin, me tavallaan ohjaamme teidät[br]läpi molempiin tasoihin asiaankuuluvien

0:08:02.400,0:08:06.080
haavoittuvuuksien avulla, jotta ymmärrettäisiin mitä tämä tarkoittaa.

0:08:06.080,0:08:11.760
Ensiksi Fritz ohjaa teidät mielenkiintoiseen ABI-tason alempaan toimintakenttään.

0:08:11.760,0:08:15.440
Kyllä vaan. Ja kuten Jo jo mainitsitkin,

0:08:15.440,0:08:21.840
se on CPUn tila ja sovelluksen binäärirajapinta. Mutta katsotaanpa

0:08:21.840,0:08:27.200
hiukan mistä puhutaan. Periaatteessa se tarkoittaa sitä, että hyökkääjä

0:08:27.200,0:08:39.348
hallitsee CPUn rekistereiden sisältöä....Jokaisella enklaavin sisään- ja ulostulolla

0:08:39.348,0:08:46.480
täytyy suorittaa tehtäviä. Eli enklaavilla ja

0:08:46.480,0:08:56.560
luotetulla ajoympäristöllä[br]on tietty CPU vaihe ja kääntäjä voi

0:08:56.560,0:09:03.360
työskennellä niiden kutsujen kanssa, joita se odottaa. Nämä ovat siis avainosia.

0:09:03.360,0:09:09.120
Meidän täytyy alustaa CPU rekisterit enklaaviin saapuessamme ja

0:09:09.120,0:09:15.520
siivota ne poistuessamme. emme voi siis olettaa mitään

0:09:15.520,0:09:20.960
hyökkääjän meille antamaa annetuksi. Meidän täytyy alustaa se joksikin kunnolliseksi ja käytettäväksi.

0:09:20.960,0:09:30.320
Tutkimme useita TEE ajoympäristöjä ja löysimme paljon

0:09:30.320,0:09:37.840
haavoittuvuuksia tältä ABI kerrokselta. Ja yksi tämän tutkimuksen[br]pääoivalluksista onkin se

0:09:37.840,0:09:45.120
että monet näistä haavoittuvuuksista sijoittuu monimutkaisien ohjesarjojen prosessoreihin,

0:09:45.120,0:09:51.760
siis CISC ja SGT TEE:issä. Tutkimme myös joitain

0:09:51.760,0:09:57.840
RISC prosessoreita, ja vaikka ei pidä yleistää, niin on heti huomattavissa,

0:09:57.840,0:10:06.000
että monimutkaisella x86 ABIlla on huomattavasti suurempi

0:10:06.000,0:10:13.760
hyökkäyspinta-ala kuin yksinkertaisemmissa [br]RISC arkkitehtuureissa. Katsotaanpa yhtä esimerkkiä tästä

0:10:13.760,0:10:20.080
monimutkaisesta arkkitehtuurista.[br]Esimerkiksi x86:ssa merkkijono ohjeistus,

0:10:20.080,0:10:26.800
jota säätelevät suuntaliput. X86:ssa on erityinen ohjeistus, joka

0:10:26.800,0:10:33.200
periaatteessa mahdollistaa striimatut muistitoiminnot. Jos bufferiin

0:10:33.200,0:10:40.960
tehdään muistin käsittelyyn toimintosarja, se käännetään merkkijonon toiminto-ohjeeksi.

0:10:40.960,0:10:50.720
Merkkijono siis luetaan vasemmalta oikealle ja ylikirjoitetaan

0:10:50.720,0:10:56.880
muistin käsittelysarjan toiminnolla. Mutta tuo lippu mahdollistaa myös käsittelyn päinvastoin,

0:10:56.880,0:11:03.200
takaperin. Ei ajatella sitä miksi tämä oli hyvä ajatus tai mihin sitä

0:11:03.200,0:11:08.720
tarvitaan. Mutta varmasti on siis mahdollisuus kääntää lippu toiseen asentoon ja lukea

0:11:08.720,0:11:16.000
bufferin sisältö takaperin. Ja mitä me [br]huomasimme: System-V ABIn mukaan

0:11:16.000,0:11:21.120
tämä lippu täytyy olla asettamatta tai olla asetettu eteenpäin(vasemmalta oikealle).

0:11:21.120,0:11:26.880
Ja kääntäjä olettaa tämän olevan näin. Katsotaanpa kuinka tämä tapahtuu

0:11:26.880,0:11:33.840
enklaavissa. Jos ajamme tämän enklaavin sisällä, luotetussa ympäristössä

0:11:33.840,0:11:39.680
normaalilla syötteellä normaalilla

0:11:39.680,0:11:45.040
normaalilla lipulla, voimme nähdä, että ajo

0:11:45.040,0:11:51.680
tapahtuu aivan oletetusti oikein päin. Jos hyökkääjä kuitenkin pääsee

0:11:51.680,0:11:58.880
ja muuttaa lippuasetuksen toiseksi,

0:11:58.880,0:12:05.840
ja pointerin kohdasta riippuen näemme ajon nyt menevän takaisinpäin luennassa.

0:12:05.840,0:12:10.640
Siinä on ongelma. ja sitä emme selvästikään

0:12:10.640,0:12:16.193
halua tapahtuvan luotetussa sovelluksessamme, koska

0:12:16.193,0:12:22.880
koska kuten voitte kuvitella, [br]se mahdollistaa niiden avainten ylikirjoittamisen,

0:12:22.880,0:12:27.280
jotka ovat muistipaikassa, jossa voit lukea takaperin.

0:12:27.280,0:12:32.960
Se mahdollistaa tiedon ulosluvun eikä se ole hyödyllistä. Kun saimme tämän raportoitua, se

0:12:32.960,0:12:38.960
johti CVE:n syntymiseen korkealla score-arvolla, kuten näette seuraavalla dialla.

0:12:38.960,0:12:46.800
Ja se on vain yksi instanssi. Täytyyhän tässä ajatella nyt

0:12:46.800,0:12:54.400
kaikkia lippuasetuksia joita täytyy ylläpitää ja tarkistaa. Mutta, tietenkin

0:12:54.400,0:13:02.960
on aina vielä jotain muutakin, eikö totta?[br]Huomasimme myös,

0:13:02.960,0:13:07.440
että FPU:ssa (matemaattisten toimintojen osaprosessointi) on paljon muita rekistereitä ja paljon [br]muita

0:13:07.440,0:13:17.040
haavoittuvuuksia hyväksikäytettävänä. Enkä mene nyt yksityiskohtiin. Mutta tähän nyt

0:13:17.040,0:13:25.704
vielä lisäksi, on olemassa [br]vanhempi x86 ja ja uudempi SSE

0:13:25.704,0:13:31.920
jotka suorittavat liukulukulaskentaa.[br]Eli on olemassa FPU ohjaussana ja MXCSR

0:13:31.920,0:13:39.849
rekisteri näitä uudempia ohjeita varten. Ja tämä x86 on vanhempi, mutta sitä yhä käytetään

0:13:39.849,0:13:45.680
esim. pitkien double muuttujien laskennassa. Eli ikä ei

0:13:45.680,0:13:49.120
tässä kohtaa ole määrittelevää, koska niin vanha kuin uusikin on tässä tapauksessa yhä ajankohtaisia.

0:13:49.120,0:13:58.160
X86 ja x87 ovat yhä olemassa ja se että voitaisiin sanoa että vanhat muinaiset jotka ovat

0:13:58.160,0:14:03.280
vanhentuneita, ovatkin yhä [br]käytössä ja siten huomioitava. Jos katsotaan

0:14:03.280,0:14:09.200
System-V ABIa, huomasimme että nämä ohjausbitit ovat kutsujatallenteisia. [br]Niitä siis

0:14:09.200,0:14:13.680
säilytetään läpi funktiokutsujen.[br]Ja ideanahan on, mitä pidetään jossain määrin saavutuksena,

0:14:13.680,0:14:22.400
että nämä ovat globaaleja tiloja, niitä välitetään

0:14:22.400,0:14:27.680
koko sovellukselle. Yksi sovellus voi siis asettaa arvon

0:14:27.680,0:14:35.280
ja se pysyy läpi niiden käyttöajan.[br]Mutta ongelma on, kuten näette

0:14:35.280,0:14:39.760
on että sovelluksemme tai enklaavimme on periaatteessa yksi sovelluskokonaisuus, emmekä todellakaan halua

0:14:39.760,0:14:44.480
hyökkääjän ottavan haltuunsa luotettua sovellustamme, eikö totta?

0:14:44.480,0:14:52.502
Mitä siis tapahtuu jos FPU asetukset säilytetään eri kutsujen ajan?

0:14:52.502,0:14:57.760
Sanotaanko että normaalikäyttäjälle, teemme laskentaa enklaavissa. Kuten

0:14:57.760,0:15:03.280
2.1 kertaa 3.4 on 7.14, mikä on tyyppinä pitkä double.

0:15:03.280,0:15:09.680
Tämä on OK? Mutta mitä tapahtuu jos hyökkääjä saapuu enklaaviin

0:15:09.680,0:15:15.680
mukanaan saastutettuja määritelmiä FPU:lle? Saamme vääristyneitä

0:15:15.680,0:15:21.520
tuloksia ja huonommalla tarkkuudella.

0:15:21.520,0:15:26.400
Itse asiassa tässä se pyöristää alaspäin, aina kun

0:15:26.400,0:15:31.280
tulos ylittää tarkkuuden. Ja sitähän emme halua? Tämä on jotain,

0:15:31.280,0:15:38.240
missä kehittäjä odottaa tiettyä tarkkuutta tai pitkän doublen tarkkuutta,

0:15:38.240,0:15:43.840
mutta hyökkääjä itse asiassa[br]supistaa tulosta ja sen tarkkuutta.

0:15:43.840,0:15:49.760
Raportoimme tästä ja itse asiassa löysimme tämän aiheen myös Microsoft OpenEnclavesta. Siksi

0:15:49.760,0:15:55.600
tätä ei ole merkitty hyväksikäytön mahdollisuudeksi. Mutta mitä huomioimme mielenkiintoisena kohtana on, että Intel

0:15:55.600,0:16:01.200
SGX SDK, joka oli haavoittuvainen, korjasi tämän xrstore[br]ohjeella.

0:16:01.200,0:16:10.400
Tämä säilyttää täysin tilan tiettynä arvona, kun taas OpenEnclave

0:16:10.400,0:16:16.320
säilytti vain tietyn rekisteriarvon, joka oli kohteena, ldmxcst ohjeessa.

0:16:16.320,0:16:19.600
Ohitetaanpa muutama dia tässä vaiheessa, koska haluan

0:16:19.600,0:16:27.120
painottaa, että tämä ei ollut tarpeeksi.[br]Huomiomme mukaan, vaikka tämä tietty rekisteri säilytettiin,

0:16:27.120,0:16:32.640
on muita rekistereitä,

0:16:32.640,0:16:40.000
joita voi merkitä käytössä oleviksi[br]ennen enklaaviin saapumista, ja johon hyökkääjä voi

0:16:40.000,0:16:45.600
muuttaa laskentatuloksen ei-numeraaliseksi. Tämä on hiljaista,

0:16:45.600,0:16:50.080
eikä siis ohjelmointikieliriippuvaista, eikä kehittäjäriippuvaista. Tämä on

0:16:50.080,0:16:55.840
hiljainen ABI asia, että laskenta ei ole ainoastaan numeroita.

0:16:55.840,0: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.

0:17:03.600,0:17:09.600
säilyttääkseen tämän laajennetun tilan. Siihen vaadittiin kaksi CVE:tä, mutta nyt

0:17:09.600,0:17:15.760
ne suorittavat täyden hallinnan. En halua mennä nyt tutkimustemme ytimeen, vaan

0:17:15.760,0:17:21.280
haluan nyt osoittaa näiden tutkimuksiemme tarkoituksen.

0:17:21.280,0:17:29.440
Tutkimme näitä tapahtumia ja halusimme selvittää,

0:17:29.440,0:17:36.800
ovatko ne vain vaikeita vaiko huonoja toteutuksia. Huomasimmekin, [br]että

0:17:36.800,0:17:41.680
ylivuotoja voidaan käyttää sivukanavana salaisuuksien päättelemiseen. Esimerkiksi,

0:17:41.680,0:17:49.120
hyökkääjä voisi käyttää [br]rekisteriä poikkeusten paljastamiseen jotta

0:17:49.120,0:17:58.400
sitten enklaavin sisällä voitaisiin laukaista syöteriippuvaisesti kerrontaa.

0:17:58.400,0:18:03.040
Lisäksi havaitsimme, että näiden sivukanavien kautta voidaan

0:18:03.040,0:18:11.920
käyttää syötetilan binäärietsintään.

0:18:11.920,0:18:16.880
Ja me voimme [br]palauttaa tämän moninkertaistamisen määriteltyihin

0:18:16.880,0:18:23.920
määrään vaiheita. Jos meillä on vain yksi maski, jonka käännämme voimme

0:18:23.920,0:18:31.760
itse asiassa palauttaa toiminnon määriteltyihin vaiheisiin.

0:18:31.760,0:18:36.560
Ja jotta tietäisimme, voimme tehdä myös enemmän. Voimme suorittaa myös koneoppimista

0:18:36.560,0:18:44.080
enklaavissa.[br]Jo mainitsikin, että sitä voidaan tehdä TEEn sisällä, pilvessä. Ja

0:18:44.080,0:18:47.760
se on koneoppimisessa mukavaa, eikö totta? Tehdäänpä hiukan käsinkirjoitetun luvun

0:18:47.760,0:18:55.200
tunnistamista. Jos ajattelemme mallia, jossa toinen

0:18:55.200,0:19:00.560
käyttäjä käyttää [br]koneoppimismallia

0:19:00.560,0:19:05.520
ja toinen käyttää enklaavia.

0:19:05.520,0:19:10.960
Kaikki on turvallista, mutta huomasimme, että voimme saastuttaa näitä FPU

0:19:10.960,0:19:18.320
rekistereitä ja näin alentaa [br]koneoppimisen suorituskykyöä

0:19:18.320,0:19:24.160
siten, että vain 8 prosenttia merkeistä tulkitaan oikein. Ja

0:19:24.160,0:19:31.600
kaikki luvut olivat itse asiassa tuloksissa samoja,

0:19:31.600,0:19:37.520
joten tämä koneoppiminen on tässä kohtaa hyödytöntä, eikö vain? Lisäksi voimme

0:19:37.520,0:19:42.320
hyökätä kuvamuutoksia sekoittamalla, pienien kuvamuutosten ja sekoitettujen kuvien

0:19:42.320,0:19:48.720
välillä. Tämä, jotta nähtäisiin, että on pieni mutta monimutkainen asia

0:19:48.720,0:19:56.480
ja ilmaisee että kaikki voi mennä pieleen nopeasti ABI tasolla, jos siellä puuhailee.

0:19:56.480,0:20:02.560
Tässä on kyse siis CPU tiloista. Nyt voidaankin puhua lisää

0:20:02.560,0:20:06.400
sovellusten ohjelmointi rajapinnasta, joka onkin [br]hiukan mukavampi

0:20:06.400,0:20:09.440
aihe olettaisin.[br]Joo, otetaan vaan, kiitos

0:20:09.440,0:20:14.160
Otetaanpa tähän melko yksinkertainen esimerkki.

0:20:14.160,0:20:18.560
Oletetaan, että lataamme standardin unix binäärin enklaaviin, ja siellä on toiminnot sitä varten,

0:20:18.560,0:20:24.960
vaikkapa graphene. [br]Ja mitä haluan esittää tällä esimerkillä;

0:20:24.960,0:20:29.680
On hyvin tärkeää tarkistaa, mistä osoittimet ovat lähtöisin. Koska

0:20:29.680,0:20:34.686
enklaavi tavallaan osittaa muistin luotettuun enklaaviin ja ei-luotettuun muistiin,

0:20:34.686,0:20:40.800
ne ovat erillisissä muistialueissa. Ongelma tässä on seuraava; Oletetaan että

0:20:40.800,0:20:47.120
meillä on binäärin kaiutus, joka ainoastaan tuo näytölle input-arvon. Annamme toiminnolle argumenttinä[br]merkkijonon

0:20:47.120,0:20:52.720
ja se normaalisti kaiuttaa sanotaanko "Hello, world", merkkijonon joka on ei-luotetussa

0:20:52.720,0:20:58.480
muistissa. Kaikki sujuu kuten pitääkin,

0:20:58.480,0:21:03.040
enklaavissa ajetaan komennot, se saa pointerin ulkopuoliseen muistiin ja printtaa merkkijonon.

0:21:03.040,0:21:08.800
Ongelmana on kuitenkin se, että enklaavilla on pääsy

0:21:08.800,0:21:15.520
myös omaan suojattuun muistiinsa. Jos hyökkääjä pääsee

0:21:15.520,0:21:20.640
käsiksi pointeriin ja ohjaa sen jonkin suojattavan tiedon kohtaan,

0:21:20.640,0:21:25.200
toiminto printtaa tiedon ulos, eikö niin? Eli äkkiä tämä onkin muuttunut muistin

0:21:25.200,0:21:32.080
sulku haavoittuvuudeksi. Ja se nähdään tässä

0:21:32.080,0:21:35.840
tapahtumassa mainitsemassani graphene ympäristössä. Meillä on siis

0:21:35.840,0:21:40.640
yksinkertainen hello world -merkkijono ja sitä käsitellään parin argumentin avulla.

0:21:40.640,0:21:45.440
Ja nyt, muutamme enklaavin ulkopuolella pointeria

0:21:45.440,0:21:50.080
enklaavin muistissa. Seurauksena se printtaa halutun

0:21:50.080,0:21:55.120
sijasta enklaavin [br]muistissa sijaitsevan suojatun tiedon.

0:21:55.120,0:22:00.960
suojatun tiedon. Tämän tyyppiset haavoittuvuudet

0:22:00.960,0:22:05.600
ovat melko tunnettuja kernelien tutkinnasta ja muistakin yhteyksistä. Niitä

0:22:05.600,0:22:11.600
kutsutaan niemllä confused deputy ( hämmentynyt apulaissheriffi). Sheriffillä on ase lukemiseen, [br]mutta ei

0:22:11.600,0:22:17.280
tiedäkään ongelman sattuessa mitä tehdä,

0:22:17.280,0:22:22.000
kun ei alun perin tarkistanut kenelle muistipaikka kuuluu tai kuka sitä hallitsee.

0:22:22.000,0:22:27.600
Tämä haavoittuvuus tuntuisi olevan helposti ratkaistavissa. Yksinkertaisesti

0:22:27.600,0:22:31.680
tarkistetaan koko ajan mitä osoitin tulee. Mutta kuten sanottu,

0:22:31.680,0:22:37.920
se ei aina ole helppoa. Kyllä David, on melko [br]tarkkanäköistä,

0:22:37.920,0:22:41.840
jos sanoo että meidän tulisi tarkistaa kaikki osoittimet. Niinpä me teimmekin.Tarkistimme kaikki

0:22:41.840,0:22:46.320
pointereihin liittyvät tarkistukset ja huomasimme että Endolla on mielenkiintoinen tapa

0:22:46.320,0:22:49.760
tarkistaa nämä kaikki. Toki, koodi on korkealaatuista. He tarkistivat

0:22:49.760,0:22:53.360
kaikki pointerit, mutta asioiden eteen on tehtävä jotain erityistä. Puhumme nyt

0:22:53.360,0:22:57.840
C ohjelmointikielestä. Käsittelyä ei siis erityisesti päätetä.

0:22:57.840,0:23:02.880
Ne loppuvat uuteen tavuun ja funktiota voidaan käyttää samalla kun taistellaan

0:23:02.880,0:23:05.920
tiedon pituuden kanssa. Ja miten tarkistus tehdään, kun tieto

0:23:05.920,0:23:10.880
on täysin muistialueen ulkopuolella?[br]Ensimmäinen askel on käsitellä pituus,

0:23:10.880,0:23:15.600
se on 10, ja sitten tarkistetaan alkaako ja loppuuko tietoalue

0:23:15.600,0:23:19.280
kokonaan kohteen ulkopuolella. Kuulostaa paikkansapitävältä. Sitten päästetään

0:23:19.280,0:23:23.760
höyryä. Tuntuu toimivan hienosti. Kuinka tämä toimii,

0:23:23.760,0:23:26.440
kun yhdistetään eri ajoympäristöt. Emmekä nyt ajattele sitä, että koko setup on enklaavin ulkopuolella,

0:23:26.440,0:23:34.160
johon salattu merkkijono välitetään.[br]Ensimmäinen askel

0:23:34.160,0:23:38.320
on enklaavin aloittama käsittely merkkijonon pituuden suhteen.

0:23:38.320,0:23:42.960
Kuulostaa melko mehukkaalta, mutta [br]onneksi kaikki

0:23:42.960,0:23:46.800
menee hyvin, kun huomataan että koko toimintoa ei olisi pitänyt tehdäkään ja

0:23:46.800,0:23:50.880
koko toiminto on itse asiassa enklaavin sisällä. Pyyntö siis hylätään

0:23:50.880,0:23:56.080
merkkijonon suhteen. Eli OK. Mutta kuten jotkut teistä tietävät,

0:23:56.080,0:24:00.160
tämä on mielenkiitoista, koska [br]English kilpaili asiasta,

0:24:00.160,0:24:04.080
mistä ei koskaan pitänyt.[br]Ja tuon kilpailun pituus määrittyy

0:24:04.080,0:24:10.480
1-bittien määrästä tehtäväannossa. Eli meillä on tässä sivukanava, jossa English

0:24:10.480,0:24:16.080
palauttaa aina arvon False. Mutta aika, joka

0:24:16.080,0:24:21.600
tuon arvon määrittämiseen menee, riippuu 0-tavujen määrästä Arncliffe

0:24:21.600,0:24:26.640
muistiblokissa. Sen me löysimme. Olimme innoissamme ja sanoimme sen olevan yksinkertainen aikaikkunaongelma.

0:24:26.640,0:24:31.920
Tällä mennään, eli tuon teimme ja näette sen tässä graafissa,

0:24:31.920,0:24:36.480
ja se osoittautui hankalammaksi kuin miltä näyttää. Sininen

0:24:36.480,0:24:39.840
1 mittaisen merkkijonon ja tuo on 2-mittaisen merkkijonon. Mutta

0:24:39.840,0:24:43.760
mitenkään ei voida graafista päätellä, koska siinä 6 prosessoria toimii

0:24:43.760,0:24:47.920
kovalla vauhdilla ja että yksi lisäys on täysin

0:24:47.920,0:24:52.560
hävinnyt kanavaan. Sitä ei pysty selvittämään mittamalla käsittelyaikaa.

0:24:52.560,0:24:59.120
Tarvitaan siis jotain muuta. Meillähän on viisaita kirjoituksia

0:24:59.120,0:25:03.920
kirjallisuudessa, esimerkiksi hyvin yleisistä hyökkäyksistä ASICeihin, joista myös Intel kirjoittaa.

0:25:03.920,0:25:09.520
Voitte nähdä, mitkä muistiblokkien sivut ovat käytössä, kun

0:25:09.520,0:25:14.080
English ajaa, koska hallitset käyttöjärjestelmää ja [br]sivutusmekanismeja.

0:25:14.880,0:25:19.680
Sitä siis yritimme tehdä ajatellen että se onkin mukava sivukanava.

0:25:19.680,0:25:24.480
Raavimme päätämme katsoessamme yksinkertaista ja lyhyttä luuppia koodissa,

0:25:24.480,0:25:29.040
ja lyhyttä merkkijonoa joka sopii kokonaisuudessaan yhdelle muistisivulle.

0:25:29.040,0:25:33.920
Vaikka meillä on pääsy muistiin, se ei auta meitä tässä, koska

0:25:34.560,0:25:39.440
koodi ja data mahtuvat molemmat samalla sivulle.

0:25:39.440,0:25:44.320
Tämä on siis väliaikainen ratkaisu, se ei ole tarpeeksi tarkka.

0:25:44.320,0:25:51.040
Eli paljon on käsiteltävää ja olemme toimineet mielenkiintoisessa

0:25:51.040,0:25:55.120
ympäristössä. Se käyttää epäsuoria osoituksia ja sitä sanotaan isoksi askeleeksi. Se on siis

0:25:55.120,0:26:01.280
täydellinen viitekehys esimerkiksi Hadoopissa. Ja mitä se itse asiallisesi mahdollistaa

0:26:01.280,0:26:05.200
sinun tehdä, on ajaa enklaavia askel kerrallaan, nimestään huolimatta.[br]Se siis myös mahdollistaa

0:26:05.200,0:26:09.040
hyökkääjän puuttumisen koodin ajoon jokaisen ohjeen tai käskyn välissä.

0:26:09.040,0:26:12.640
Ja miten me sen esitämme, on hyvin teknistä. Meillä on Linuxin kernelin

0:26:12.640,0:26:18.480
ajo pienen kirjastokäyttöjärjestelmän ympärillä, mutta se

0:26:18.480,0:26:23.200
ei ole ihan asian ydin. Asia on siinä, että voimme pysäyttää enklaavin

0:26:23.200,0:26:27.538
jokaisen komennon jälkeen ja rauhassa pohtia, mitä voisimme tehdä.

0:26:27.538,0:26:33.720
Mitä me ite asiassa voimme tehdä, on ajaa ja seurata tätä lisäkoodia

0:26:33.720,0:26:38.918
yksi kerrallaan ja jokaisen keskeytyksen jälkeen [br]yksinkertaisesti tarkistaa,

0:26:38.918,0:26:45.066
saavuttaako enklaavi merkkijonon sieltä mihin olemme sen osoittaneet.[br]Se on toinen

0:26:45.066,0:26:50.683
tapa ajatella asiaa, että meillä on ajo enklaavissa ja se voidaan rikkoa

0:26:50.683,0:26:56.998
osiin ja laskea osat.

0:26:56.998,0:27:03.440
Päättäväistä ajoittamista. Tosin sanoen meillä on ennustaja joka kertoo

0:27:03.440,0:27:08.824
missä 0-tavut sijaitsevat. En tiedä onko se käytännöllistä, itse asiassa on.[br]Osoittautuu

0:27:08.824,0:27:12.737
olevan niin, että jotkut jotka ovat syntyneet hyökkääjiksi,

0:27:12.737,0:27:17.760
tietävät jo, että on hyvä tietää, missä kohta [br]muistia nollat ovat. Ja

0:27:17.760,0:27:23.537
nyt osoitamme esimerkin, missä rikomme A-S:n ja Iowan, jotka ovat kiihdytyskovona

0:27:23.537,0:27:29.000
yrityksen AI prosesseissa. Ja [br]nämä toimivat ainoastaan rekistereissä.

0:27:29.000,0:27:34.130
Juuri mainittiin, että tavallaan pidetään tuosta yksittäisestä osoituksesta muistiin,

0:27:34.130,0:27:38.832
mutta heti on olemassa toinenkin [br]temppu. Eli aina kun enklaavi on

0:27:38.832,0:27:44.080
keskeytetty, se säilöö senhetkiset rekisterinsä ja ajan johonkin muistilokeroonsa kehyksenä,

0:27:44.080,0:27:50.425
joten voimme keskeyttää ja verifioida sen tekevän oikein.

0:27:50.425,0:27:56.840
Ja sitten voimme ajaa tämän 0-tavu ennustajan tässä

0:27:56.840,0:28:02.722
SSA muistissa. Ja mitä löydämme; missä 0 on tai onko siellä nollia lainkaan.

0:28:02.722,0:28:08.747
En kuitenkaan halua mennä tarkemmin siihen, jos vastaus [br]on kyllä. Mutta mitä

0:28:08.747,0:28:15.835
itse asiassa teemme, kun löydämme nollan viimeisestä vaiheesta

0:28:15.835,0:28:21.850
ennen viimeistä lisäyskierrosta ja sitten huomaamme että nolla kaatuu ja muuttuu X:ksi

0:28:21.850,0:28:27.520
tai avaintavuksi, ja saamme tulokseksi salattua tekstiä. Me kuitenkin tiedämme

0:28:27.520,0:28:33.601
salatekstin tavun, ja voimme palata takaisin päin.

0:28:33.601,0:28:39.763
salatekstin tavun, ja voimme palata takaisin päin.

0:28:39.763,0:28:45.840
Tämä ketju toistetaan 16 kertaa, kunnes on löydetty jokainen 0,

0:28:45.840,0:28:51.460
ja meillä on käsissämme koko avain.

0:28:51.460,0:28:56.294
Ja ne jotka tietävät, jos on käsissä yksi avainkooste on käsissä myös koko avain.

0:28:56.294,0:29:00.654
Jos siis saat alkuperäisen avaimen, voit ajaa takaperin. Kuulostaa

0:29:00.654,0:29:05.988
monimutkaiselta, mutta se on hyvin nopea hyökkäys minkä voit seuratessa todeta.

0:29:05.988,0:29:11.473
Tässä on siis esimerkki tämän hyökkäyksen tekemisestä, ja kuten huomasitte muutamassa sekunnissa

0:29:11.473,0:29:16.342
ja noin 520 Asirin hyödyntämisellä, saamme koko KeIson.

0:29:16.342,0:29:21.401
Se on melko vaikuttavaa. Yksi keskeisimmistä

0:29:21.401,0:29:26.268
asioista on se, että muistiin ei itse asiassa laiteta mitään, mutta

0:29:26.268,0:29:33.062
toiminnassa SGX:n kanssa voit manipuloida sitä.

0:29:33.062,0:29:41.372
Haluankin tässä vaiheessa päättää tämän, olemme kuitenkin löytäneet useita muitakin haavoittuvuuksia.

0:29:41.372,0:29:47.838
Sekä tutkimus- että tuotantokoodissa, kuten Intelin tai

0:29:47.838,0:29:52.708
Microsoftin SDK:ssa.[br]Ja ne menevät läpi koko alueen käyttäen

0:29:52.708,0:29:57.700
vieraita kykyjä, joita on nähty muuallakin tutkimuksessa.

0:29:57.700,0:30:02.680
Mutta, on olemassa myös uudenlaisia mielenkiintoisia esittämiimme aspekteihin liittyviä haavoittuvuuksia.

0:30:02.680,0:30:08.240
Oli myös ongelmia kaikkien kutsuvälitysten kohdalla,

0:30:08.240,0:30:13.770
kun enklaavi kutsui ulkopuolellaan olevia osia.

0:30:13.770,0:30:18.740
Kutsuja joita käytetään emuloimaan järjestelmäkutsuja ja niin edelleen.[br]Ja jos palautat

0:30:18.740,0:30:24.839
tässä yhteydessä ollain tavalla väärän tuloksen, voidaan taas lipsahtaa rajojen ulkopuolelle. Ne myös

0:30:24.839,0:30:30.697
olivat erittäin, erittäin laajalle levinneitä. Ja lopuksi löysimme jotain tapauksia

0:30:30.697,0:30:36.115
liittyen paddingiin (kryptauksen toiminto). en taaskaan halua mennä yksityiskohtiin.

0:30:36.115,0:30:40.880
Olemme todenneet tässä asiassa, että voimme tehdä vertauksia oikeaan maailmaan.

0:30:40.880,0:30:47.105
On tärkeää pestä kätensä, eli on tärkeää huoltaa ja tiloittaa osoittimet

0:30:47.105,0:30:54.213
ja niin edelleen. Se on eräänlainen [br]poistumisviesti,

0:30:54.213,0:30:58.585
jolla kääntää ja ottaa yhteys turvallisesti.

0:30:58.585,0:31:03.445
Kyllä, kaikki kovo-ongelmat täytyy ratkaista, mutta koodin täytyy olla turvallista.

0:31:03.445,0:31:09.674
Enklaavien tapauksessa se tarkoittaa kunnollisia APIa ja APIen huoltoa. Tämä on itse asiassa erittäin

0:31:09.674,0:31:15.718
vaikea tehtävä, mielestäni

0:31:15.718,0:31:21.066
hyökkäyspinta-ala on suuri, erityisesti älykkään X:n

0:31:21.066,0:31:25.781
tapauksessa, missä voit keskeyttää jokaisen toimen ja niin edelleen. Mielestäni tutkimuksen

0:31:25.781,0:31:31.888
näkökulmasta, tarvitaan siis enemmän. Näkökulmasta jatkat jos haluat,

0:31:31.888,0:31:38.010
ehkä voimme oppia [br]jotain käyttäjästä analogiaan johon viittasin.

0:31:38.010,0:31:43.734
Luullakseni tätä tarvitaan, jotta ymmärretään mitä

0:31:43.734,0:31:48.650
enklaavin pitäisi tehdä verrattuna siihen mitä colonelin pitäisi [br]tehdä.

0:31:48.650,0:31:54.239
Ne ovat kuitenkin tärkeitä eroavaisuuksia, jotka tulisi ottaa huomioon. Joten luulisin,

0:31:54.239,0:31:59.670
kuten sanoit, kaikki koodimme [br]on avointa lähdekoodia.

0:31:59.670,0:32:07.016
Joten kaiken esitellyn voit löytää allaolevien Github -linkkien kautta

0:32:07.016,0:32:15.077
ja tietenkin voitte esittää kysymyksiä tämän esityksen katsomisen jälkeen.[br]Eli kiitoksia paljon.

0:32:15.077,0:32:21.680
No niin, olemme palanneet jälleen. Ja tässä kysymyksiä?

0:32:21.680,0:32:28.200
Ei vielä kysymyksiä....Voitte siis laittaa kysymyksiä tulemaan... Suljenpa nyt tämän

0:32:28.200,0:32:36.751
ja kysynkin nyt kysymyksiä teiltä. Miten päädyitte tähän aiheeseen ja miten tapasitte toisenne?

0:32:36.751,0:32:43.484
No se onkin melko mielenkiintoista. Ajattelen sen olevan

0:32:43.484,0:32:50.158
rakentuneen pitkällä aikavälillä vuosien saatossa.[br]Luulisin sen olevan tulosta

0:32:50.158,0:32:56.691
alkuperäisten suunnitelmiemme haavoittuvuuksista, Aloitin itse asiassa väitöskirjassani perusteiden keräämiseksi.

0:32:56.691,0:33:01.763
Emme itse asiassa nähneet koko kuvaa ennenkuin tapasimme

0:33:01.763,0:33:06.774
Davidin ja hänen kollegfansa Birminghamista Lontooseen. [br]Mukava konferenssi.

0:33:06.774,0:33:11.326
Ja sitten aloimme tehdä yhteistyötä ja toimia

0:33:11.326,0:33:14.955
systemaattisemmin. Aloitin tämän haavoittuvuuksien listaamisen

0:33:14.955,0:33:19.880
ja sen jälkeen teimme Davidin kanssa systemaattisemman analysoinnin.

0:33:19.880,0:33:26.362
Ja se oli se Pandoran lipas,

0:33:26.362,0:33:32.003
samoja virheitä toistaen. Sitten Fitzhugh, joka liittyi seuraamme hiljattain

0:33:32.003,0:33:36.237
Lontoossa, alkoi työskennellä kanssamme

0:33:36.237,0:33:40.520
matalan tason Sebu ominaisuuksien kanssa. Ja se itsessään on jo Pandoran lipas.

0:33:40.520,0:33:46.506
Sanoisin että erityisesti yksi opetus, kuten sanoimme, oli tuo tietty kuutonen, joka on erityisen monimutkainen.

0:33:46.506,0:33:51.233
Ja tuota kaikkea kompleksisuutta voidaan hyväksikäyttää, erityisesti

0:33:51.233,0:33:55.904
biodiversiteettiä. Se on kuin osa moniosaisuudesta,

0:33:55.904,0:34:01.831
missä avaat laatikon ja saat vastaukseksi yhä lisää kysymyksiä.

0:34:01.831,0:34:08.731
On mielestäni reilua sanoa, että tämä tutkimus ei ole

0:34:08.731,0:34:13.573
lopullinen vastaus aiheeseen, mutta se on yritys löytää järjestelmällinen tapa

0:34:13.573,0:34:19.068
tarkastella loputtomia perusteita.

0:34:19.068,0:34:26.034
Netin kautta on tullut kysymys. Onko muita olosuhteita missä

0:34:26.034,0:34:33.188
Mianus kirjoittaa rekistereihin, kuin juuri SGX?

0:34:33.188,0:34:44.160
Täytyy sanoa, etten myöskään ymmärrä kysymystä, mutta kokisin sen niin

0:34:44.160,0:34:49.280
että onko tulos taktinen häviö? Vankila riippuu siitä, että kun on muistin huollon

0:34:50.000,0:34:54.720
yhteydessä meitä syytetään sisällön muistiin

0:34:54.720,0:34:58.960
pakottamisesta.

0:35:00.000,0:35:05.040
Eli se on ehdottomasti hmmm.

0:35:05.040,0:35:08.960
Sanoisin kuitenkin että yksi opetuksista viimeisen viiden tutkimusvuoden aikana on,

0:35:08.960,0:35:13.200
että usein nämä asiat [br]yleistyvät kuutosen jälkeen[br]ja ainakin yleisesti,

0:35:13.200,0:35:18.880
oivallus SEBUsta, että oikeellisuus muistin käsittelyssä saavutetaan tavalla tai toisella, [br]ennemmin tai myöhemmin.

0:35:18.880,0:35:23.040
Mielestäni tuo pätee järjestelmien luomisessa, että jos jotenkin voi pakottaa

0:35:23.040,0:35:26.080
käyttöjärjestelmän kompleksisuuten [br]sovellusten osalta,

0:35:27.200,0:35:32.160
rekistereitten käyttö muistissa on pakollista. Jos teillä olisi jotain samankaltaista mitä

0:35:32.160,0:35:37.200
meillä on käyttöjärjestelmässä, Colonelissä, teillä olisi [br]potentiaalinen hyväksikäytön paikka.

0:35:37.760,0:35:43.680
Mutta ehkä David haluaa jotain käyttöjärjestelmistä myös.

0:35:43.680,0:35:48.240
Ei en oikeastaan.[br]Ajattelisin, että eräs asia mikä helpottaa SGX:n

0:35:48.240,0:35:53.200
kanssa on tiukka kontrolli, kuten mainitsit, keskeytysten ja muun [br]kanssa,

0:35:53.200,0:35:58.080
kun olette matkallanne enklaavin ulkopuolella. Voitte siis askeltaa käytännössä koko

0:35:58.080,0:36:03.280
enklaavin, kuten keskeyttämällä koko käyttöjärjestelmän.

0:36:03.280,0:36:08.320
Tarkoin toistettuna [br]oikeassa kohdassa joku toinen prosessi

0:36:09.120,0:36:13.760
on taipuvainen olemaan vaikeampi suunnittelultaan. Mutta kontekstissa, jossa

0:36:13.760,0:36:19.360
meidän täytyy tallentaa jotain turvaan, se on

0:36:19.360,0:36:25.840
rekisterit joista se päätyy muistiin, [br]joissain tilanteissa

0:36:25.840,0:36:34.480
vähemmän kontrolloidusti kuin esim. Asgeirssonin tapauksessa. On siis olemassa kysymys, entä muut CPU -arkkitehtuurit

0:36:34.480,0:36:41.840
kuin Intel, testasitteko niitä? Ehkä voin mennä hiukan tähän, mielenkiintoista.

0:36:41.840,0:36:48.160
Intelhän on suurin, sillä on suurin ohjelmistoalusta ja eniten ajossa olevia ympäristöjä.

0:36:48.160,0:36:53.440
Sitähän me voisimme tutkia.[br]Mutta tietenkin on olemassa muutakin,

0:36:53.440,0:37:01.040
kuten muutama vuosi sitten kehittämämme Sancho's.

0:37:01.040,0:37:05.440
Ja tietenkin silläkin on [br]samat aiheet. Eli aina tarvitaan

0:37:05.440,0:37:14.880
ohjelmistokerros jonka täytyy päästä enklaaviin.[br]Luullakseni

0:37:14.880,0:37:20.880
David aikaisemmassa työssään löysi ongelmakohtia TEE:sämme[br]Eli tämä ei ole ainoastaan

0:37:20.880,0:37:27.120
Intel-sidonnaisten projektien sotkun paikka. Mutta mitä me

0:37:27.120,0:37:34.000
varmasti huomasimme, on helpompaa ajatella kaikkia tapauksia yksinkertaisemmissa ympäristöissä

0:37:34.000,0:37:38.080
kuin viitosessa ja sitä helpommissa, kuin kompleksisemmaassa kuutosessa.

0:37:39.360,0:37:43.840
Joten nyt ei ole paljoa ympäristöjä vähemmille tempuille.

0:37:43.840,0:37:48.880
Heillä on siis etu ja haitta olla ensimmäisiä laajasti

0:37:48.880,0:37:56.000
levinneitä, mutta luulen että kun muutkin alkavat kasvaa

0:37:56.000,0:38:00.960
ja yksinkertaisemmat arkkitehtuurit yleistyvät,näemme että

0:38:00.960,0:38:05.649
on helpompi korjata väitettyjä ongelmia niissä. OK, mikä on

0:38:05.649,0:38:18.966
järkevä vaihtoehto TEElle vai onko sitä.

0:38:18.966,0:38:27.215
Meillä molemmilla on asiaan omat perspektiivimme, näin ajattelisin.

0:38:27.215,0:38:31.842
Kysymyksen vakiintuessa, tarvitsemmeko

0:38:31.842,0:38:34.992
vaihtoehtoja vai tarvitsemmeko systemaattisempia tapoja huoltaa

0:38:34.992,0:38:39.212
Australians? Se on mielestäni osavastaus tähän, että meidän ei tarvitse

0:38:39.212,0:38:43.240
heittää tätä hukkaan, vaikka sen kanssa on ongelmiakin.

0:38:43.240,0:38:46.990
Voimme myös miettiä miten ratkaista nuo ongelmat. Mutta sen ulkopuolella meillä on jännittävää

0:38:46.990,0:38:52.124
tutkimusta. OK, ehkä David myös haluaa sanoa hieman lisää esimerkiksi

0:38:52.124,0:38:57.305
ominaisuuksista, mutta se ei välttämättä ole niin erilaista [br]tähän verrattuna.

0:38:57.305,0:39:00.864
Silloin kun on high tech tukea kuten Cherry

0:39:00.864,0:39:04.646
Borjessonin tietokoneen osalla, joka itsesiallisesti yhdistää metadatan

0:39:04.646,0:39:09.692
metadatapisteisiin, kuten tilaustarkistuksia

0:39:09.692,0:39:14.837
silloin puhumiemme aiheiden saastutushyökkäyksiä voitaisiin saada

0:39:14.837,0:39:20.651
kiinni ilman itse ilman tukea. Mutta se on hyvin korkean tason idea. Ehkä David

0:39:20.651,0:39:26.080
jhaluaasanoa jotain. Kyllä, ajattelisin että vaihtoehtona TEE:lle,

0:39:26.080,0:39:31.640
haluat osittaa järjestelmäsi, mikä on mielestäni hyvä ajatus. Jza

0:39:31.640,0:39:37.523
Ja kaikki tekevät sitä nyt, miten online palveluita tehdään ja niin edelleen.

0:39:37.523,0:39:44.276
Nämä ovat järjestelmiä jotka ovat yleistyneet

0:39:44.276,0:39:48.976
matkapuhelimissa tai vaikkapa pankkikorttijärjestelmissä,

0:39:48.976,0:39:52.729
jotka ovat suojattu ympäristö yksinkertaisille toimille. Mutta

0:39:52.729,0:39:57.501
ongelmat alkavat, kun laitetaan paljon toiminnallisuuksia tähän ympäristöön.

0:39:57.501,0:40:03.318
Kuten näimme, luotettu koodipohja [br]tulee yhä monimutkaisemmaksi ja saadaan ympäristöstä perinteinen laatikko.

0:40:03.318,0:40:08.059
On todellinen kysymys, tarvitaanko vaihtoehto vaiko

0:40:08.059,0:40:11.794
parempi lähestymiskulma aiheeseen. Miten voitte, ositusohjelmistot? Ja kuten mainitsit

0:40:11.794,0:40:16.406
on asioita joita voi hoitaa arkkitehtuurilla.

0:40:16.406,0:40:21.386
Näin voidaan laajentaa arkkitehtuureita [br]ominaisuuksilla

0:40:21.386,0:40:25.955
ja sitten aloittaa komponenttien eristäminen.

0:40:25.955,0:40:30.299
Esimerkiksi, ohjelmistoprojektissa, sanotaanko Web-serverilläsi, sinä eristät stackin tai jotain vastaavaa. Ja

0:40:30.299,0:40:37.526
kiitokset katsojille salalisen salasanan huomaamisesta,[br]sehän tehdään vain näön tähden,

0:40:37.526,0:40:45.854
antaaksemme ihmisille jotain katseltavaa.

0:40:45.854,0:40:54.612
Mutta sehän ei ole perusteiltaan viallinen?[br]Tarkoitan että niitä on niin monia,

0:40:54.612,0:41:02.261
ettet voi sanoa niiden olevan perusteiltaan viallinen, mutta

0:41:02.261,0:41:08.342
erityisesti SGX:ää [br]ajatellen, koska signaali käyttää mobiilikolikoita

0:41:08.342,0:41:15.680
kryptovaluutta käyttää sitä, ja niin edelleen ja niin edelleen. Onko se perusteiltaan viallinen

0:41:15.680,0:41:24.428
vai haluatko mieluummin sanoa niin? Sehän riippuu perusteiltaan kunnossa olevan [br]määritelmästä.

0:41:24.428,0:41:29.915
Menneisyydessä olemme työskennelleet myös

0:41:29.915,0:41:35.107
asenteiden rikkomisen parissa, mutta ne on saatu korjattua ja on aika kaunis

0:41:35.107,0:41:40.909
ja hyvin tutkittu kokonaisuus jolla on myös lyhytaikaisia vaikutuksia tuotantoon.

0:41:40.909,0:41:45.924
Löydät siis haavoittuvuuden, toimittajan on tehtävä korjaus jota ei ole olemassa

0:41:45.924,0:41:50.014
tai siihen tulee väliaikainen [br]korjaus. Sitten myöhemmin

0:41:50.014,0:41:54.432
tarvitaan uusia prosesseja jotta saataisiin lopullinen korjaus ongelmaan

0:41:54.432,0:41:58.668
ja kuitenkin siihen [br]saadaan taas

0:41:58.668,0:42:04.655
väliaikaisia korjauksia. Jos esimerkiksi yhtiö kuten Signeul käyttää

0:42:04.655,0:42:10.059
niitä, et saa oletuksena turvallisuutta. Mutta täytyy ajatella

0:42:10.059,0:42:14.108
ohjelmistoja. niihin keskitytään tässä tapauksessa.[br]Täytyy ajatella

0:42:14.108,0:42:20.394
myös laitteistoja, mikropaikkauksia ja prosessoreita joissa täytyy huolehtia kaikista

0:42:20.394,0:42:26.470
tunnetuista haavoittuvuuksista. Ja silti täytyy aina kysyä, että entä

0:42:26.470,0:42:30.824
ne mahdollisuudet joita emme vielä tunne, missään turvallisessa järjestelmässä.

0:42:30.824,0:42:36.676
Ehkä David haluaa sanoa jotain viimeisimmästä työstään.

0:42:36.676,0:42:42.504
Hiukan mielenkiintoista.[br]Ajattelenpa, että mikä tahansa lähtökohtasi

0:42:42.504,0:42:48.083
tai minun vastaukseni tähän kysymykseen olisi, riippuu tietenkin [br]uhkamallista.

0:42:48.083,0:42:54.045
Jotkut käyttävät SGX:ää siirtääkseen luotetut asiat pilvipalvelun tuottajalle,

0:42:54.045,0:42:59.511
kuten RSS tai Signaler. Siirretään [br]siis kaikki nämä toiminnot

0:42:59.511,0:43:04.655
jollekin pilvitoimittajalle enklaaviin. Tällöin minun ei tarvitse

0:43:04.655,0:43:10.673
luottaa pilvitoimittajaan, koska myös fyysiseen turvallisuuteen on jotain.

0:43:10.673,0:43:15.760
luottaa pilvitoimittajaan, koska myös fyysiseen turvallisuuteen on jotain. [br]Vähän aikaa sitten paljastimme kuitenkin haavoittuvuuden,

0:43:15.760,0:43:22.130
joka osoittaa, että jos sinulla on fyysinen pääsy SGX:ään,

0:43:22.130,0:43:28.138
voit injektoida prosessorin pelaamalla voting rajapinnalla, joka on laitteistossa.

0:43:28.138,0:43:33.155
Siinä todellakin nähtiin, että pari johtoa emolevyn väylältä

0:43:33.155,0:43:38.442
jännitteen säätimeen. Saadaan aikaan jännitepiikki,

0:43:38.442,0:43:43.824
kuten [br]voitte tietääkin.

0:43:43.824,0:43:48.680
Sillä tavalla voidaan kääntää bittejä enklaavissa

0:43:48.680,0:43:54.589
ja näin tietenkin tehdä kaikenlaista

0:43:54.589,0:43:59.612
pahuutta, kuten injektoida, [br]jonka avulla taas voidaan saada avaimia, kaapata ohjaus, tai jotakin. Se siis riippuu

0:43:59.612,0:44:04.802
uhkamallista. En sanoisi niin, että ASX on täysin turha. Sekin

0:44:04.802,0:44:10.200
on parempi kuin ei mitään. Mutta [br]ehdottomasti, et voi olla

0:44:10.200,0:44:15.314
täysin turvassa jos jollain on fyysinen pääsy palvelimellesi.

0:44:15.314,0:44:20.880
Nyt minun täytyy lopettaa keskustelu, pahus sentään. Ja kysyisin kaikki kysymykset

0:44:20.880,0:44:26.100
jotka sain. Mutta hyvin lyhyt [br]vastaus, kiitos. Mikä tuo juttu on tuon

0:44:26.100,0:44:30.627
salasanan kanssa tuolla taustalla?[br]Minähän selitin sen, se on vaan puhdas vitsi.

0:44:30.627,0:44:35.609
Sanon sen vielä kerran, koska jotkut näyttävät ottaneen sen vakavasti. [br]Se on

0:44:35.609,0:44:40.438
vain tilan täytteeksi.[br]Laitoin sen vaan sinne sen takia. Se ei muutoin olekaan kokonaan sieltä luettavissa, onneksi.

0:44:40.438,0:44:46.234
Minun täytyy varmasti ottaa ja avata David Oswaldin kirja.

0:44:46.234,0:45:00.100
Kiitokset hyvätä keskustelusta ja nyt siirrytäänkin seuraavaan

0:45:00.100,0:45:03.840
esitykseen.

0:45:03.840,0:45:34.000
[Translated by Kari Kananoja (ITKST56 course assignment at JYU.FI)] 2023