TTKK / Tietoliikenne / J.Koskinen : Tietoturvallisuuden perusteet

5. viikko, ke 29.9.1999

Tietokannat

Tähän asti on tarkasteltu enempi hajallaan olevia kohteita: tiedostoja, ohjelmia, viestejä, transaktioita tai kokonaisia organisaatioita. Tietokanta on ainakin loogisessa katsannossa melko yhtenäinen ja selvärajainen kohde. Siitä pitää huolta hallintajärjestelmä (DBMS), jonka kautta käyttäjä on yhteydessä siihen, olipa itse tieto sitten tallennettu mihin järjestykseen ja miten hajautetusti hyvänsä.

Seuraava esitys soveltuu osittain myös sellaisiin tietojoukkoihin, joita ei yleensä mielletä tietokannoiksi. Tällaisia ovat koneen käyttäjäluettelo, pääsynvalvonnan tiedostot, verkonhallinnan informaatiokanta MIB, nimipalvelimen tiedot, reitittimen tiedot jne.

Tietokannoille ominaisia turvaongelmia

Laitteiston särkymisen, tavanomaisen kaatumisen ja muiden fyysisten seikkojen lisäksi kirjoitus tai sen puuttuminen voi aiheuttaa seuraavanlaisia eheysongelmia:

vahingossa väärät syöttötiedot: kerätty, laskettu tai vain kirjoitettu väärin;
asiattomien tekemät tahattomat tai tahalliset virheet;
saman tiedon ristiriitaiset tai toisteiset ilmentymät (esim. kun kannan tietoja koostetaan eri lähteistä);
eri tahoilta tulevat samanaikaiset muutokset (esim. lukumäärätietoon jonka lähtöarvon kumpikin on lukenut ennen muutosta).

Lukeminen tuottaa ongelman luottamuksellisuuden suhteen lähinnä sellaisissa tietokannoissa, joissa osa tiedoista on julkisia ja osa täytyy suojata sivullisilta. Jos kaikki tieto olisi samaa lajia, voitaisiin koko järjestelmä hallita kyseisen lajin mukaisin keinoin ja ongelmia olisi korkeintaan käyttöjärjestelmän tasolla.

Arkaluonteinen tieto voi tietokannassa ilmetä yksinkertaisimmillaan siten, että jotkin tietueet tai jotkin kentät ovat luottamuksellisia. Arkojen tietojen paljastumista ei aina saisi tapahtua edes osittain. Tiedosta tai sen luonteesta voi kertoa liikaa esimerkiksi

arvon vaihteluväli tai todennäköisyys jollekin arvolle;
olemassaolo tai -olemattomuus (rikosrekisteri, jokin kenttäotsikko tietueessa, tai yhtä hyvin: sejase ei ole käyttäjänä tietyssä koneessa);
komplementtitieto (attribuutin arvo ei ole jokin).

Tässä tullaan osittain jo päättelyprobleeman alueelle: Erityisongelma tietokannoissa ovat nimittäin päättelyt tietoja yhdistelemällä: luottamukselliseen tietoon voidaan päästä käsiksi useiden vähemmän arkojen tietojen perusteella tyypillisellä "salapoliisin työllä". Erityisesti yhteenvetotiedot, kuten lukumäärät ja keskiarvot voi olla luokiteltu vähemmän aroiksi, samoin sellaiset näkymät, joissa luetellaan kaikista tietueista vain jokin kenttä.

Esimerkki: Opiskelijoiden yksityisyyttä voidaan suojella julkaisemalla tenttituloslistoissa ainoastaan opiskelijanumerot ilman nimiä. Karkea virhe olisi tällöin päästää ketään asiatonta käsiksi luetteloon, jossa on sekä nimet että numerot. Toisaalta kursseista voi olla nimet sisältäviä ilmoittautumislistoja tms. Yhdistämällä riittävän paljon eri kurssien tietoja on mahdollista laatia tällainenkin luettelo. Käytännössä tämä vaatisi tietysti paljon enemmän työtä kuin ihmisiltä kyselemällä saada selville kuka mitäkin sai tentistä.

Eri tietokannoista tehtävät yhdistelmät ovat vain hieman eri asia, mutta paljon hankalampi. Se on jo tullut esille tietosuojan yhteydessä, henkilörekisterien tapauksessa ...

Tietokantojen yleiset turvallisuustavoitteet

Fyysinen eheys: koskee laitteistoa ja sitä että ainakin tietyntasoisista vahingoista voidaan toipua, edellyttää normaalia varmuuskopiointia osana käyttöjärjestelmän toimia. Tästä ja fyysisestä turvasta yleisesti lisää jäljempänä.
Looginen eheys: rakenteen säilyminen eheänä, erityisesti viittaukset ja tietojen vaikutus toisiin tietoihin.
Tietoalkioiden eheys ja oikeellisuus.
Toimijoiden vastuullisuus: mahdollisuus jäljittää, ketkä ovat käyneet kohteissa tai muuttaneet niitä.
Pääsynvalvonta (kuten yleensäkin:) tietyt henkilöt vain tiettyjä toimia vain tietyille tiedoille.
Käyttäjien autentikointi, mahdollisesti vielä sen lisäksi mitä käyttöjärjestelmän puitteissa on tehty.
Käytettävyys: tietokannan yleinen ja pääsynvalvonnan mukainen saatavillaolo.

Mekanismeja

Tietokantojen turvamekanismien pitää yleensä olla hienojakoisempia kuin käyttöjärjestelmän tarjoamat, sillä nämä eivät ylety tekemään erotteluja tiedostojen sisällä. Tietokannassa taas jokainen tietue voidaan joutua ottamaan huomioon erikseen. Sellaisena ongelma on kuitenkin samantapainen kuin tiedostoissa. Miten suojeltava kohde sitten rajataankin, eri toimijoiden erityyppiset oikeudet siihen pitää määritellä ja panna toimeen pääsynvalvonnan tekniikoilla.

Eheysmekanismeja

Eheyden tarkistus kenttiä syötettäessä: joko
- kenttäkohtaisesti asetetun ehdon perusteella, esim. arvon oltava numeerinen joltain väliltä, päivämäärä, tai sen on täytettävä jokin sanastollinen ehto; tai
- kokonaisuuden perusteella. Yksinkertaisimmillaan avaimeksi määritellyn kentän pitää olla erisuuri eri tietueissa, tai tietynlaisten tehtävänimikkeiden kohdalla palkalla on tietyt rajat. Tällaisten yhtä tilaa koskevien rajoitusten ohella voidaan rajoittaa tilasiirtymiä, eli tietojen muutokset voivat edellyttää joitain alkuehtoja ja/tai joitain muita muutoksia (esim. tilausrajan alitus aiheuttaa tilauksen, joka pitää merkitä tietokantaan).
Tällaisissa on yhtäältä kyse siitä, miten tietokannan eheys on määritelty (siis tavallaan tietoturvapoliittinen kysymys), ja toisaalta miten hallintajärjestelmä pystyy ottamaan kaiken huomioon.
Kaksivaiheinen päivitys: aikomus ja päätös ('commitment'). Yksinkertaisesti tulkittuna tämä on varsin yleinen turvamekanismi ja sopii moneen yhteyteen. Esimerkiksi tiedostojen tuhoamisessa voidaan tehdä ensin 'delete' tai 'remove' roskakoriin ja vasta eri komennolla 'expunge', 'purge' tai 'empty', jolla kori tyhjennetään.
Tietokannan tapauksessa on usein kyse siitä että niputetaan monivaiheinen kokonaisuus (transaktio), jossa toimen keskeytyminen tai muiden väliintulo voisi särkeä eheyden. Tällöin aikomusvaiheessa tehdään tarvittavat valmistelut (tiedoston avaukset, toisten sulkeminen pois samalta alueelta, ...), kerätään kaikki tarpeellinen tieto ja tehdään laskutoimet, mutta ei vielä muuteta mitään. Päätöksen jälkeen nostetaan "commit"-lippu ja kirjoitetaan sen suojissa uudet arvot. Jos tämän aikana tulee keskeytys, kirjoitus voidaan toipumisen jälkeen tehdä kokonaan uudestaan. Lopuksi lasketaan lippu.
Aikomusvaihe kuvaa tietokannan hallintajärjestelmän toimia eikä esim. matkatoimiston käyttöliittymän ääressä tehtyä pohdintaa: Siinä vaiheessa, kun esim. paikkavaraus varsinaisesti aiotaan tehdä, hallintajärjestelmä estää muita edes lukemasta samaa tietoa ja jos tieto mahdollistaa varauksen (eli paikka tosiaan on vielä vapaa), aikomusvaihe pääsee eteenpäin.
Muutoslogi, eräänlainen "on-line backup", joka mahdollistaa "undo"-toiminnon, eli tehtyjen muutosten peruuttamisen - enemmän tai vähemmän pitkälle historiaan. Mekanismi on tuttu monista tekstureista, mutta sitä voi soveltaa laajemminkin jolloin peruuttaminen on mahdollista myös täysimittaisen vahingon jälkeen - vaikka sitten varmuuskopion ja paperilla olevan login avulla.
Muu redundanssi: muutoksen kohteena olevan tietokantataulun tai tiedoston alkuperäinen versio voi olla kopioituna levyllä, kunnes suoritetaan talletus tai operaatio on kokonaan valmis. Operoinnin aikana voidaan myös säännöllisin väliajoin tehdä varmistustalletuksia rinnakkaiseen tiedostoon, joka istunnon päätyttyä joko hävitetään tai jätetään. Tällaista redundanssia voi kutsua varjotiedoksi.
Kirjoitusoikeuden rajoitukset voidaan joutua erittelemään tarkemmin kuin yleensä tiedostoissa: mahdollisia vakiotoimiahan ovat tietueen lisääminen tai poistaminen, vanhan tiedon muuttaminen tai pelkkä uuden liittäminen jatkoksi. Rakenteen muuttaminen esim. lisäämällä uusia kenttä tai poistamalla vanhoja ei yleensä kuulu tavallisen käyttäjän toimiin, eivätkä myöskään pääsyoikeuksien muutokset.

Luottamuksellisuuden tavoittelua

Tavanomaisten pääsynvalvonnan ja sitä edeltävien autentikoinnin mekanismien lisäksi voidaan soveltaa seuraavanlaisia "päättelyn kontrollin" menetelmiä:

suppean aineiston sääntö: kysely hylätään jos tulos (esim. lukumäärä) perustuisi hyvin pieneen määrään tietueita, jotka kuitenkin muodostavat suuren osan jonkin laajemman ehdon mukaisista tietueista (joka saataisiin esim. jättämällä jokin "ja"-ehto pois).
tulosten yhdistelmät: hylätään kysely, jos sen tuloksena olevien tietuieiden joukko on suurelta osin (mutta ei tarkkaan) sama kuin edellisellä kerroilla.
satunnaisotos, josta kyselyn tulokset muodostetaan (suuren tietokannan tapauksessa)
vaihteluvälien ilmoittaminen tarkkojen arvojen sijasta
satunnainen muuntelu, pertubaatio, jolla tietoa hieman vääristellään mutta tulos on silti suuntaa-antava
kyselyanalyysi: Tietokantapalvelin voi pitää kirjaa käyttäjän aiemmista kyselyistä (jopa aiemmilla käyttökerroilla) ja laskea, voiko se enää vastata uusiin kyselyihin antamatta käyttäjälle tilaisuutta tehdä yhdistelmiä, johon tällä ei ole oikeutta. Ymmärrettävästi tätä on kuitenkin erittäin vaikea toteuttaa.

Jos jokin tietue halutaan pitää salaisena, mutta toisaalta siinä on tietoja, joiden pitäisi olla julkisia (esim. epäluulojen välttämiseksi), voidaan tehdä kaksi tietuetta, joista toinen sisältää kaikki tiedot ja toinen vain sen mikä voidaan näyttää julkisesti. Tempun tekninen nimi on "polyinstantiation". Tällainen toisteisuus voi olla myös haitallista ja sellaiseen voidaan joutua kun alemmin oikeuksin varustetut toimija lisää jonkin tiedon joka kuitenkin on jo kannassa mutta ylemmässä turvaluokassa ja siksi häneltä näkymättömissä. Tämä on yksi esimerkki monitasoisen tietokannan ongelmista.

Monitasoinen tietokanta

Turvaluokitukseltaan monitasoista tietoa sisältävässä tietokannassa voidaan soveltaa edellä kuvattujen menettelyjen sijasta tai lisäksi esim. seuraavia. Näistä kaksi ensimmäistä edustavat aiemmin mainittuja fyysistä ja kryptograafista erottelumekanismia ja lopuilla pyritään loogiseen erotteluun ja siihen että käyttäjän kannalta tietokantaan säilyisi yhtenäinen näkymä - ikäänkuin häneltä kiellettyjä tietoja ei olisikaan.

Jaetaan kanta yksinkertaisesti turvaluokituksen mukaisiin erillää toimiviin osiin - kovin kankea järjestely, mutta joissain tapauksissa mahdollinen.
Salataan arat tiedot. Jos tietyllä turvaluokalla on yksi ja sama avain, alemman luokan käyttäjä saattaa yrittää valitun selvätekstin hyökkäystä tallettamalla itseään kiinnostavan tiedoalkion ylemmälle tasolle. Tämän jälkeen hän pystyy kääntämään tuloksena olevan kryptotekstin missä muualla se esiintykään. Tämä ongelma voidaan torjua muuntelemalla avainta vaikkapa tietueen avainkentän perusteella tai ketjuttamalla tietueen kenttien salaus CBC-moodin tapaan. Joka tapauksessa ongelmana on kyselyiden toteuttamisessa vaadittava alituinen dekryptaus.
Jokaiseen tietueeseen tai jopa kenttään asennetaan (eheys- tai arkuus-)lukko, joka vastaa dokumentin turvaleimaa. Lukkoa käsittelee luotettu pääsynvalvontajärjestelmä, jonka kautta tavallinen tietokantajärjestelmä käsittelee kantaa. Jotta lukkoa ei voi kopioida toiseen paikkaan eikä väärentää, sen osana on tarkistussummaa, joka on laskettu salaisella avaimella tietuenumerosta, turvaleimasta ja tiedosta, jota itseään ei tarvitse salata.
Asetetaan tietokantaohjelma luotettavan käyttöliittymän eli vahdin ('guard') ja luotettavan pääsynvalvontajärjestelmän väliin. Vahti tarkistaa kyselyä lähettäessään käyttäjän oikeudet ja tuloksia vastaanottaessaan niiden luvallisuuden ja suodattaa tarvittaessa. Jos vahti suodattaa myös toiseen suuntaan eli muokkaa kyselyä, puhutaan kommutatiivisesta suodattimesta. Yleisemminkin, jos tietokantaohjelma suunnitellaan alusta pitäen ottamaan turvallisuus huomioon, siitä tulee luontevasti monikerroksinen - itse tietokanta ytimenä ja käyttöliittymä päällimmäisenä. Luotettu
Tietokannan hallinta voidaan jakaa kahden tavallisen tietokantaohjelman vastuulle siten, että toinen käsittelee alempien tasojen ja toinen ylempien tasojen tietoja. Luotettu käyttöjärjestelmä toimii näiden molempien ja käyttäjän välissä. Järjestelmää voidaan toteuttaa joko ajamalla kahta tietokantaohjelmaa samassa koneessa ("fragmented architecture") tai eri koneissa ("replicated architecture").

Fyysinen turvallisuus

Ensimmäisillä luennoilla mainittiin jo fysikaalisia tietoturvauhkia tulesta ja vedestä alkaen. Fyysinen turvallisuus tarkoittaa suojautumista muunkinlaisilta uhkilta käyttäen kuitenkin fysikaalisia keinoja, jotka ulottuvat prosessorista rakennuksiin.

Harjoitus: Keksitään ja kirjataan fysikaalisia keinoja, joilla tietokonelaitteistoja ja niissä olevia tietoja voidaan suojata erilaisilta uhkilta.

Eräänlaiset perusteet kaikelle tietoturvalle voi tarkistaa työajan jälkeen tehtävällä tarkastuskierroksella, jossa katsotaan ovatko (1) työhuoneiden ovet, (2) laatikot ja kaapit sekä (3) työasemat lukossa, (4) levykkeet turvassa ja (5) tärkeät paperit yms. turvassa. Kaikkia näitä seikkoja pitää muistaa soveltaa myös työaikana, erityisesti puhtaan (työ)pöydän politiikkaa.

Muita huomioon otettavia seikkoja ovat laitteiston sijoittelu; fyysinen pääsy tiloihin; kaapelointi katonrajassa valekaton yläpuolella: onko sielläkin palovaroittimet; verkon liityntäpisteiden sijainti; virran saatavuus; huollon ja ylläpidon saatavuus; varmuuskopioiden talletuspaikka.

Varmuuskopiointi on jo tullut monessa yhteydessä esille. Fyysisen turvallisuuden näkökulmasta varmuuskopio pitäisi toimittaa melko kauas koneesta, vähintään eri huoneeseen, mieluummin johonkin toiseen rakennukseen.

Vakavamman vahingon sattuessa ei riitä, että tiedot ovat tallessa. Toiminnan nopea jatkaminen voi vaatia uusia laitteita ja uusia toimitiloja. Laitteiden hankkiminen ei ole yleensä ratkaiseva ongelma mutta sopivat tilat voivat olla. Tällaisia tilanteita varten voidaan varautua rakentamalla varatila ("cold site"), johon laitteisto voidaan asentaa lyhyessä ajassa. Kriittisemmät sovellukset voidaan joutua varmistamaan valmiilla asennuksilla, jossa voidaan ottaa huomioon myös varahenkilökunnan saanti lyhyellä varoitusajalla ("hot site"). Tällainen kannattaa yleensä tehdä useamman tahon yhteistyössä, jolloin kustannukset ovat kohtuulliset.

Turvalliset prosessorit; Tamper-resistance

Yleiset vaatimukset turvalliselle tieto(kone)järjestelmälle: Järjestelmän pitää pystyä erottamaan, ovatko siihen kohdistuvat toimet sallittuja vai eivät. Järjestelmän käyttäjän pitää tietää, onko järjestelmä aito vai onko sitä peukaloitu, eli onko jokin ei-sallittu toimenpide päässyt vaikuttamaan järjestelmään Peukalointia voi olla myös poikkeuksellisen lämpötilan, säteilyn tai syöttövirran käyttö.

Peukaloinnin ('tampering') ehkäisyyn on useita lähestymistapoja:

tamper evidence: peukalointia ei voi tehdä ilman että siitä jää fyysisiä jälkiä.
tamper resistance: peukalointi on tehty vaikeaksi.
tamper detection: laite itse "tiedostaa", jos sitä peukaloidaan.
tamper response: laite reagoi aktiivisesti peukalointiin, esim. nollaamalla sisältönsä.

Näitä voi verrata esim. laitteisiin, joita kiinnitetään omaisuuteen tai myytäviin tuotteisiin varkauksien estämiseksi.

FIPS-standardi 140-1 määrittelee turvallisille prosessoreille neljä tasoa. Korkeimmalle turvatasolle hyväksyttyjä laitteita on erittäin harvassa.

Turvaprosessorissa joudutaan ottamaan huomioon itse laitteen lisäksi koodi ja sen lataaminen. Huomioitavia seikkoja ovat

laitteen valmistus ja alustus, ja tässä yhteydessä myös se, pitääkö valmistajan tai jonkin auktoriteetin säilyttää jotain tietoa jokaisesta laitteesta;
koodin turvallinen päivitys: onko uusi versio aito;
turvallinen koodin ajaminen;
laitteen pitää pystyä todistamaan koskemattomuutensa ulospäin.

Lähde: S.W.Smith, S.Weingart: Building a high-performance, programmable secure coprocessor. Computer Networks Vol31 No8, 1999, 831-860.

Muuan turvallisuutta edistävä mekanismi on "trusted (communication) path"(-näppäin), jollainen esim. IBM:n AIX-unixissa on "secure attention key" (SAK). Tämän painalluksen jälkeen vain luotetut ohjelmat pääsevät käyttäjän päätteelle. Erityisesti tällä torjutaan (teurastetaan) Troijan hevosen tyyppiset ohjelmat jollaisen, joku on voinut asentaa päätteeseen login-ohjelman tilalle (tai eteen) varastaakseen salasanan. Tietenkin verkon ylitse tapahtuvassa sisäänkirjautumisessa tällainen näppäinkoodi menettää merkityksensä, sillä se voidaan väärentää.

Toimikorttien turvallisuus

Toimikortille voidaan tallettaa henkilökohtaisia tietoja, esim. biometrisiä tietoja (siis "elomittoja"), terveystietoja, autentikointiin käytettäviä avaimia (myös esim. GSM:n SIM-kortissa eli Subscriber Identity-Modulissa), ja toisaalta enemmän tai vähemmän anonyymia rahaa. Kortit voivat suorittaa julkisen avaimen krypto-operaatioita paljastamatta salaista avaintaan, mutta esim. RSA-alkulukujen generointi kestäisi liian kauan. Samoin sarjamuotoinen tiedonsiirto on turhan hidas, jotta symmetrisiä salausta kannattaisi soveltaa laajoihin aineistoihin. Useimmat ladattavat bittirahat perustuvat symmetriseen salaukseen, mikä edellyttää luottamusta siihen, että (rahastavassa) lukulaitteessa olevan vastaava avain pysyy turvassa.

Toimikortin tekniikka perustuu ISO:n standardiin 7816. Sitä selostetaan mm. SCIAn, eli Smart Card Industry Associationin sivuilla. USA:ssa vastaavan standardin nimi on PCMCIA (Personal Computer Media Control Interface Adapter). Suomalaisen Avant-kortin takaa löytyy myös valmisteilla oleva eurooppalainen standardi prEN 1546 (prelimanary Euronorm: Inter-sector Electronic Purse). Standardeista huolimatta eri valmistajien kortit eivät varsinkaan toiminnoiltaan ole yhteensopivia.

Toimikortti muodostuu kun tietyn kokoiselle (ja lujuiselle jne) muovikortille tiettyyn kohtaan liimataan piisiru ja varustetaan tietyillä liityntänastoilla. Sirun täytyy olla varsin pieni, muutaman millin kokoinen, jotta se voisi kestää kortin taipuessa.

Sirun tyypillinen sisältö on

8-bittinen CPU ja mahdollisesti oheisprosessori kryptografiaa varten;
RAM työmuistina (0.25-1kB);
ROM kiinteitä ohjelmia ja käyttöjärjestelmää varten (6-24 kB);
EEPROM muuttuvaa mutta tallessa pysyvää tietoa (kuten avaimia) varten (Electronically Erasable Programmable Read-Only Memory, 1-16kB).

Sirun laitteistomäärityksistä, joihin tyypillisesti kuuluu myös käyttöjärjestelmä (laitelmisto), käytetään englannissa termiä 'mask'.

Sirun liityntänä on 8 nastaa:

VCC GND
RST RFU
CLK I/O
RFU VPP

Näistä 5 tai 6 on nykyään käytössä: VCC: käyttöjännite n. 5V; GND: maadoitus; RST: reset, tällä signaalilla kortinlukija alustaa ja lopettaa yhteytensä korttiin; RFU = reserved for future use; CLK: kello, n. 3.6 tai 4.9 MHz; VPP: ohjelmointijännite E(E)PROM-muistiin kirjoittamiseksi 12.5-21 V, ei yleisesti käytössä EEPROM-muisteilla (koska tarvittava jännite voidaan nykyään "pumpata" sirun sisällä); I/O: sarjamuotoinen luku ja kirjoitus RS232:n tapaan, yleensä tavupohjaisesti.

Kortin elinkaaressa on useita vaiheita, joissa asteittain yhä enemmän kortilla olevaa tietoa jää vaiheen suorittajan ulottumattomiin, joko kokonaan tai kortin oman prosessorin myötävaikutuksen taakse. Tällä saavutetaan yksi kortin turvallisuuden keskeisistä ideoista eli se, että ulkopuolelta voi ainoastaan estää toimintaa, ei väärentää sitä. Lisäksi valmistusvaiheiden aikana toteutetaan useita varotoimia, jotta mikään yksi taho ei saisi täyttä tietoa sirun rakenteesta, salaisista avaimista eikä henkilökohtaisista tiedoista. Velvollisuuksien eriyttäminen "need-to-know"-periaatteella on näissä vaiheissa tyypillistä, samoinkuin yhtä useamman henkilön edellyttäminen tiettyjen avainten käsittelyyn. Elinkaaren vaiheet ovat karkeasti seuraavanlaiset:

Prosessorisirun valmistus: testauksen jälkeen tähän tarkoitukseen käytetyt liitynnät eliminoidaan polttamalla "sulakkeet", sirun ROM:iin tähän mennessä talletettu ohjelmisto on salattu sirukohtaisella avaimella, jotta tuntematon taho ei voi tehdä muutoksia. Valmistenumerot lisätään.
Kortin toimittaja istuttaa sirun kortille ja liittää siihen ulospäin näkyvät kytkentänastat. Valmistusvaiheen avain korvataan toisella ja sen muuttaminen ehkäistään lukkobitillä. Fyysisen muistiviittauksen käskyt ehkäistään polttamalla sulake, minkä jälkeen vain looginen muistiviittaus on mahdollista (ja lukkobittikin siis tehoaa).
Henkilöinti, jonka tekee kortin myöntävä taho: Loput tiedot kirjoitetaan kortille, erityisesti PIN, PUK ja salaiset avaimet. Lopuksi käyttölukkobitti asetetaan osoittamaan, että käyttövaihe on alkanut.
Käyttö, jossa pääsy tietoihin rajoittuu sovelluksen politiikan mukaiseksi.
Käytöstä poistaminen, joko niin että lukuoikeus säilyy, tai ettei sekään ole mahdollista.

Tiedostojärjestelmä muistuttaa unixia hakemistoineen. Tiedostoon pääsy voi olla: aina sallittua, vain omistajalle mahdollisesti eri tarkoitusten mukaan (vrt. PIN₁ ja PIN₂ HST-kortissa), hallinnollinen, ei koskaan.

PIN-hallinto: PIN (Personal Identification Number) on talletettuna tiettyyn tiedostoon ja sitä voi muuttaa samaan tapaan kuin salasanaa. Liian monta peräkkäistä väärä PIN-syöttöä lukitsee tiedoston. Pääsy edellyttää tämän jälkeen sekä oikean PIN-arvon että PUK-arvon (PIN Unblocking Key) syöttämistä, mutta myös PUK voi mennä lukkoon, jolloin kortti ainakin tämän PIN-arvon takana olevalta osalta siirtyy pois käytöstä. Tällainen on toiminta kortin kannalta. On eri asia, onko kortin omistajan hallussa oleva PUK-koodi "kokonainen" vai onko se jaettu kortin myöntäjän kanssa, jolloin tarvitaan yhteistoimia lukon avaamiseen.

Hyökkäyksiä (valmista) korttia vastaan:

Looginen hyökkäys: normaalinkaltaisessa käyttöympäristössä kortin kanssa käytävästä kommunikaatiosta (tai vaikkapa virrankulutuksesta) yritetään selvittää salaisuuksia. Tätä voidaan tehdä myös siinä tapauksessa että PIN on saatu selville. Salaiset avaimethan eivät tällöinkään tule näkyviin, vaan ainoastaan käytettäviksi; kyseeseen voi siis tulla "valittu teksti"-tyyppinen kryptoanalyysi.
"Fyysis-looginen" hyökkäys käyttää epänormaalia jännitettä tai lämpötilaa, kellotaajuuden vaihtelua tai säteilyä saadakseen aikaan poikkeavaa käytöstä, joka voi paljastaa kortin tietoja.
Fyysinen hyökkäys voi tunkeutua edellisiä pitemmälle sirun sisuksiin.
Toisenlainen hyökkäys voisi olla kortinlukijaa käyttävään työasemaan asennettu Troijan hevonen, joka suorittaa omia operaatioitaan (esim. allekirjoitusta) samalla "oven avauksella", tarvitsematta saada selville PIN:ä.

Lisätietoa toimikorteista ja turvallisuudesta saa sujuvasti artikkelista S. Petri: An Introduction to Smartcards. Toinen toimikorttien turvallisuutta käsittelevä artikkeli on S.C. Chan: An Overview of Smart Card Security. Hyökkäyksiä ja niiden torjuntaa on esitelty edellisiä tieteellisemmässä artikkelissa Andersson, Kuhn: Tamper Resistance - a Cautionary Note. Hyvin yksityiskohtaista mutta tiivistä tietoa löytyy liki 200-kiloisen raportin "Security of Electronic Money" jatkeena olevasta liitteestä 5, josta on paikallinen kopio.