1 Lyhenneluettelo 3
2 Johdanto 4
3 Tietoturva ja -turvattomuus 5
3.1 Uhkatekijät 5
4 OVT-viestintä ja tietoturva 6
4.1 Vaatimukset 6
4.2 Standardointi 6
4.3 Käytäntö 7
4.4 Segmentit 7
4.4.1 USA - Security Algorithm 8
4.4.2 USR - Security Result 8
4.4.3 UST - Security Trailer 8
4.4.4 USC - Certificate 9
4.4.5 USH - Security Header 10
5 Nykytilanne 11
5.1 Suomessa 11
5.1.1 PATU (Pankkien asiakasyhteyksien tietoturva) 12
5.2 Maailmalla 13
6 Tulevaisuus 14
7 Yhteenveto 14
8 Lähdeluettelo 15
1 Lyhenneluettelo
ANSI X3.92-1981 Standard for Data Encryption Algorithm
ANSI X3.106-1983 Standard for Information Systems - Modes of Operation
AUTACK Authentication Aknowledgement
DEA Data Encryption Algorithm
DES Data Encryption Standard (tunnetuin symmetrinen salakirjoitusmenetelmä)
DSA Digital Signature Algorithm
DSS Digital Signature Standard (ehdotettu digitaalinen allekirjoitusstandardi)
EDIFACT Electronic Data Interchange for Administration Commerce and Trade
ElGamal Eräs digitaalinen allekirjoitusalgoritmi
IDEA International Data Encryption Algorithm
ISO International Standardisation Organisation
ISO 8730 Banking - Requirements for message authentication
ISO 8731 Banking - Approved algorithms for message authentication
ISO 8732 Banking - Key management
ISO 9735 Standard for EDIFACT
ISO 10126 Banking - Procedures for message encipherment
MAC Message Authentication Code
RC2 Symmetrinen blokkitason salakirjoitusalgoritmi
RC4 Symmetrinen nopea bittitason (stream) salakirjoitusalgoritmi
RSA Rivest, Shamir, Adleman (tunnetuin julkisen avaimen salakirjoitusmenetelmä)
SJWG Security Joint Working Group
UN United Nation (YK)
Siirtyminen kohti tietoyhteiskuntaa on tuonut tullessaan vaatimuksia, joiden kanssa tämänpäivän tietotekniikan ammattilaiset painivat. Päätöksiä tehdään yhä useammin tietokoneavusteisesti, nopeasti. Tuntikin on joskus liian pitkä aika, toisaalta liian lyhyt siihen, että tietoa ei aina ehditä analysoida ja tarkastaa tarpeeksi hyvin. Joudumme luottamaan tietokoneen antamaan tietoon ja siihen mistä tieto on peräisin. Päätös saatetaan tehdä luottaen väärään tietoon ja seurauksena voi olla katastrofi.
Elämme siis tietotulvaisessa ja -turvattomassa tietoverkkojen peittämässä yhteiskunnassa, jossa elämä vaatii tarkoituksen mukaiset turvajärjestelyt. Herrasmiessäännöt voi unohtaa tyystin, elämme virtuaalitodellisessa bittiviidakossa kunnioittaen ainostaan vahvimman oikeutta. Pitää olla tarpeeksi vahva pystyäkseen suojautua 'viidakon' uhkatekijöiltä, kräkkereiltä, viruksilta ja muilta kiusantekijöiltä.
Suurin ongelma toistaiseksi on ollut uhkatekijoiden tunnistus. Pienen ihmisen on joskus vaikea hahmottaa kokonaisuus, etenkin kun kyse on uudestä ja vaikeasta tekniikasta. Yksinkertaisesti olemme liian sinisilmäisiä, suorastaan sokeita tälle asialle. Jotain olisi tehtävä ja nopeasti välttääksemme suurkatastrofit ja voidaksemme integroida tietoturvan osaksi tietojärjestelmien infrastruktuuria.
Tietoturvattomuutena ymmärretään yleensä kolmannen osapuolen aiheuttama uhka koskien yrityksen liikesalaisuuksia. Tämä kuva lienee peräisin kylmän sodan ajoilta, jolloin ihmisille luotiin romanttinen kuva agenttien vaarallisista toimista vieraan vallan hermokeskuksissa luvattomasti tietoa hankkien. Tämä toiminta tuntee myös nimen vakoilu. Näin ei asian laita enää todellisuudessa kuitenkaan ole (totuus on tosin joskus tarua ihmeellisenpää). Uhkatekijät ovat jotain aivan muuta, yleensä inhimillisiä erehdyksiä tai järjestelmävirheistä aiheutuvia. Niin tai näin, seuraukset ovat yleensä samat, joten niihin on myös varauduttava samalla vakavuudella. Tarvitaan oikea asenne.
Tahattomasti aiheutuvat uhkatekijät:
Tahallisesti aiheutetut uhkatekijät:
Kokonaan oma lukunsa on itse järjestelmän saatavuuteen, käyttöön, liittyvät uhkatekijät:
Tässä siis vain esimakua siitä, mitä meillä todellisuudessa on vastassa. Ei vain rikolliset vaan tietokoneet ja ennen kaikkea me itse, käyttäjät.
OVT-viestinnän ollessa kyseessä tietoturvan merkitys kasvaa entisestään, koska kyseessä alkavat olla melkoiset rahavirrat ja rikollisten mielenkiinto lisääntyy koko ajan, puhumattakaan heidän tietoteknisesta osaamisesta. Tähän mennessä tiedonsiirtoverkko on tarjonnut käytännössä vaaditun tietoturvatason, mutta nykypäivän trendin mukaan on suuntauduttu vahvasti kohti pakettikytkentäistä tiedon siirtoverkkoa, joka on kovin avoin kaikille edellä luetelluille uhkatekijöille. Joten haasteita on odotettavissa.
Lähdettäessä kehittämään tietoturvaa on hyvä asettaa vaatimukset ja tavoite:
UN/EDIFACT SJWG on tehnyt usean vuoden ajan työtä kehittääkseen tietoturvaa EDIFACT viestien välityksessä, edellä mainittujen vaatimusten mukaisesti.
ISO 9735 versio 4 on vielä 'working draft' -tasolla, mutta se on menossa äänestykseen toukokuussa ja sille pyritään saamaan mahdollisimman nopea käsittely. Näyttää kuitenkin todennäköiseltä, että sitä ei hyväksyttäisi, koska ehdotus lisäisi kielioppiin uuden välimerkin ja aiheuttaisi yhteensopimattomuutta olemassa oleviin järjestelmiin. Kaikki asiakkaat/asianosaiset ovat käytännössä sitä vastaan, joten paljon on vielä tehtävää ja aikaa kuluu ennenkuin standardin uusin versio näkee päivänvalon.
EDIFACT-standardi (versio 4) muodostuu yhdeksästä osasta. Näistä kolme eli osat 5, 6, ja 7 liittyvät pelkästään tietoturvaan.
Standardin puuttuminen ei kuitenkaan ennenkään ole estänyt uusien menetelmien käyttöönottoa, mutta tässä tapauksessa kyse on suuresta määrästä turhaa työtä, mikäli versiota ei hyväksyttäisiinkään. Halutaan selvästi odottaa mihin suuntaan asiat kääntyvät ennen suuria investointipäätöksiä.
Kuten vaatimuksista käy ilmi, osapuolilla on melko vapaat kädet turvapalveluiden toteutuksen suhteen. Pyörää ei kuitenkaan haluta keksiä uudestaan, joten tulevat ratkaisut tulevat nojaamaan hyvin vahvasti jo olemassa oleviin salakirjoitusmenetelmiin esim. DES, ElGamal, IDEA, RC2, RC4, RSA, Schnorr. DSS on johdettu ElGamal:sta ja Schnorr:sta, joskin RSA on tällä hetkellä maailman eniten käytetty autentikointimenetelmä ja yleisesti se toivottaisiin valittavan DSS:n DSA:ksi. Mene ja tiedä, aina parhaimmat de facto -standardit eivät saa varsinaisen standardin asemaa. RSA on todennäköisesti liian vahva esim. turvallisuuspalvelun näkökulmasta katsoen.
EDIFACT tietoturvamäärittelyissä on siis kolme selvästi toisistaan eroavaa vaatimusta: tiedon luottamuksellisuus ja eheys sekä osapuolen todennus. Näistä todennus ja eheys ovat selvästi tärkeimmät. Toki luottamuksellisuus on tarkeää, kun on kyse esim. pankkitiedoista tai sairaalan potilastiedoista.
Toteutuksessa tullaan käyttämään vähintään kahta erilaista salausalgoritmia. Julkisen avaimen algoritmilla hoidetaan tyylikkäästi osapuolten todentäminen, elektroniset allekirjoitukset. Myös tiedon eheyteen liittyvät tarkastukset hoituvat samalla periaatteella. Itse asiassa tiedon eheys ja osapuolen todennus perustuu juuri tuon hajautusfunktion arvon salaukseen julkisen avaimen salakirjoitusmenetelmällä.
Luottamuksellisuus puolestaan saadaan aikaiseksi jonkun nopean symmetrisen salakirjoitusalgoritmin hyväksikäytöllä. DES, IDEA tai RC4 lienevät vahvimpia suosikkeja. Jokaista viestiä varten generoidaan uusi avain, joka välitetään kryptattuna (julkisen avaimen algoritmilla salattuna) vastaanottajalle.
Standardi (working draft) määrittelee seuraavat tietosegmentit, joita käytetään turvapalveluiden toteutuksessa:
| TAG | Name |
| USA | Security Algorithm |
| USC | Certificate |
| USH | Security Header |
| USR | Security Result |
| UST | Security Trailer |
Taulukko 1: EDIFACT-standardin tietoturvan toteuttavat segmentit
Määrittelee käytetyn algoritmin ja miten sitä käytetään sekä sisältää käyttöön vaadittavat tekniset parametrit. Esiintyessään USH segmentin kanssa USA sisältää symmetrisiä algoritmeja tai hajautusfunktioita, USC segmentin esiintyessä USA voi sisältää myös asymmetrisiä algoritmeja.
| Pos | TAG | Name | S | R | Repr. | Notes |
| 010 | S502 | SECURITY ALGORITHM | M | 1 | ||
| 0523 | Use of algorithm, coded | M | an..3 | |||
| 0525 | Cryptographic mode of operation, coded | C | an..3 | |||
| 0533 | Mode of operation code list identifier | C | an..3 | |||
| 0527 | Algorithm, coded | C | an..3 | |||
| 0529 | Algorithm code list identifier | C | an..3 | |||
| 020 | S503 | ALGORITHM PARAMETER | C | 5 | ||
| 0532 | Algorithm parameter value | M | an..512 | |||
| 0531 | Algorithm parameter qualifier | M | an..3 |
Taulukko 2: USA segmentin rakenne ja osatiedot
Nimensä mukaisesti sisältää salausfunktioiden tulokset. Segmenttiä käytetään kahdella tavalla: USC:n kanssa käytettynä sisältönä on elektroninen allekirjoitus, USH ryhmässä käytettynä sisältönä salausalgoritmin tarkiste.
| Pos | TAG | Name | S | R | Repr. | Notes |
| 010 | S508 | VALIDATION RESULT | M | 1 | ||
| 0560 | Validation value | M | an..256 | |||
| 0560 | Validation value | C | 1 | an..256 |
Taulukko 3: USR segmentin rakenne ja osatiedot
Tämä segmentti rajaa USH segmentin vaikutusalueen. Viestistä on löydyttävä aina vastaava UST segmentti jokaista USH segmenttiä kohden.
| Pos | TAG | Name | S | R | Repr. | Notes |
| 010 | 0534 | SECURITY RESULT LINK | M | 1 | n2 |
Taulukko 4: UST segmentin rakenne ja osatiedot
Julkisen avaimen välitys ja todisteet avaimen laillisesta haltijasta löytyvät tästä segmentistä.
| Pos | TAG | Name | S | R | Repr. | |
| 010 | 0536 | CERTIFICATE REFERENCE | C | 1 | an..35 | |
| 020 | S500 | SECURITY IDENTIFICATION DETAILS | C | 2 | ||
| 0577 | Security party qualifier | M | an..3 | |||
| 0538 | Key name | C | an..35 | |||
| 0511 | Party Id identification | C | an..17 | |||
| 0513 | Code list qualifier | C | an..3 | |||
| 0515 | Code list responsible agency, coded | C | an..3 | |||
| 0586 | Party name | C | an..35 | |||
| 0586 | Party name | C | an..35 | |||
| 0586 | Party name | C | an..35 | |||
| 030 | 0544 | FORMAT CERTIFICATE VERSION | C | 1 | an..3 | |
| 040 | 0505 | FILTER FUNCTION, coded | C | 1 | an..3 | |
| 050 | 0507 | ORIGINAL CHARACTER SET ENCODING, CODED | C | 1 | an..3 | |
| 060 | 0543 | CERTIFICATE ORIGINAL CHARACTER SET REPERTOIRE, CODED | C | 1 | an..3 | |
| 070 | 0546 | USER AUTHORISATION LEVELS | C | 1 | an..35 | |
| 080 | S505 | SEPARATOR FOR SIGNATURE | C | 5 | ||
| 0548 | Separator for signature | M | an..4 | |||
| 0551 | Separator for signature qualifier | M | an..3 | |||
| 090 | S501 | SECURITY DATE AND TIME | C | 4 | ||
| 0517 | Date and time qualifier | M | an..3 | |||
| 0339 | Date, extended | C | n..8 | |||
| 0314 | Event time | C | n..15 | |||
| 0337 | Time offset | C | n4 | |||
| 100 | 0553 | SECURITY STATUS, CODED | C | 1 | an..3 | |
| 110 | 0555 | REVOCATION REASON, CODED | C | 1 | an..3 |
Taulukko 5: USC segmentin rakenne ja osatiedot
Tehtävänä määritellä objekti ja siihen kohdistuva turvamekanismi ts. kohdistetaanko mekanismi viestiin, ryhmään vai viestin vaihtoon. Paljon vartija turvamekanismia kuvattaessa.
| Pos | TAG | Name | S | R | Repr. | Notes |
| 010 | 0552 | SECURITY STRUCTURE VERSION NUMBER | M | 1 | an..3 | |
| 020 | 0501 | SECURITY FUNCTION, CODED | M | 1 | an..3 | |
| 030 | 0534 | SECURITY RESULT LINK | M | 1 | n2 | |
| 040 | 0541 | SCOPE OF SECURITY APPLICATION, CODED | C | 1 | an..3 | |
| 050 | 0503 | RESPONSE TYPE, coded | C | 1 | an..3 | |
| 060 | 0505 | FILTER FUNCTION, coded | C | 1 | an..3 | |
| 070 | 0507 | ORIGINAL CHARACTER SET ENCODING, coded | C | 1 | an..3 | |
| 080 | 0509 | ROLE OF SECURITY PROVIDER, CODED | C | 1 | an..3 | |
| 090 | S500 | SECURITY IDENTIFICATION DETAILS | C | 2 | ||
| 0577 | Security party qualifier | M | an..3 | |||
| 0538 | Key name | C | an..35 | |||
| 0511 | Party Id identification | C | an..17 | |||
| 0513 | Code list qualifier | C | an..3 | |||
| 0515 | Code list responsible agency, coded | C | an..3 | |||
| 0586 | Party name | C | an..35 | |||
| 0586 | Party name | C | an..35 | |||
| 0586 | Party name | C | an..35 | |||
| 100 | 0516 | SECURITY REFERENCE NUMBER | C | 1 | an..35 | |
| 110 | S501 | SECURITY DATE AND TIME | C | 1 | ||
| 0517 | Date and time qualifier | M | an..3 | |||
| 0339 | Date, extended | C | n..8 | |||
| 0314 | Event time | C | n..15 | |||
| 0337 | Time offset | C | n4 | |||
| 120 | 0519 | COMPRESSION FUNCTION, CODED | C | 1 | an..3 |
Taulukko 6: USH segmentin rakenne ja osatiedot
Saadakseni selville OVT:n tietoturvan nykytilan, haastattelin muutamaa OVT:n ammattilaista: Ina Michelsson (EDI Management / TT Tieto), Hannu Pelkonen (STY), Markku Holopainen (EDI Masters) ja Kari Jämsä (Scandinavian Softline Technology Oy).
Tällä hetkellä pankkeja lukuunottamatta OVT-järjestelmissä ei ole käytössä minkäänlaisia tiedonsalausta. Tiedon eheyttä ja todentamista kuitenkin pyritään kehittämään ja sitä onkin toteutettu erilaisten kuittausten muodossa. OVT-suosituksista löytyy mm. kuittaussanoma, jolla pyritään lähinnä varmistamaan sanoman perille meno. Asiantuntijoiden mukaan varsinaiseen kryptausta käyttävään tietoturvaan Suomessa on vielä vuosi pari aikaa. Ensisijaisesti halutaan kehittää tiedon eheyden valvontaa ja osapuolten todentamista. Toki aineiston sisältö sanelee tarpeen milloin aineiston olisi syytä olla salattua, toinen oleellinen kriteeri on valittu siirtomedia.
Haastateltujen mukaan äänestykseen menevä esitys pitää sisällään niin paljon syvälle EDIFACT kielioppiin meneviä asioita, että OVT järjestelmän muutokset vaativat liian paljon muutoksia tehtäväksi vapaaehtoisesti. Konsultit ovat vallanneet tämän alueen ja se saattaa olla yksi syy siihen, että esitys jää niin kauas todellisista käyttäjistä ja valmiuksista omaksua uudet määritykset.
Vaikka todellisessa käytössä ei EDIFACT:n tietoturvaominaisuuksia vielä olekaan, ei täysin kiistetty, etteikö ohjelmistotoimittajilla jo olisi valmiina tai ainakin osittain toteutettuna nuo tietoturvapalvelut.
Kaikista uhkatekijöistä huolimatta Suomessa eletään vielä jonkinlaisia herrasmiespelisääntöjä noudattaen ja toistaiseksi on vältytty pahemmilta takaiskuilta tai ainakaan niistä ei julkisesti puhuta. Nyt olisi kuitenkin se hetki käsillä, jolloin asia pitää ottaa työn alle ainakin pohdittavaksi, jotta H-hetken tullessa olisi edes kuva siitä millaisia haasteita on vastassa.
Suomessa PATU lienee tällä hetkellä ainut järjestelmä, joka toteuttaa tietoturvaa edes jossain muodossa.
Osa 1 määrittelee tiedon eheydenvalvonnan ja osapuolen todentamisen. Se on nykyään myös pakollinen asioitaessa elektronisesti pankkien kanssa.
Osa 2 puolestaan määrittelee varsinaisen tiedonsiirron salauksen, mutta julkaistaan myöhemmin, kun aineistojen salakirjoituksen menetelmiä otetaan käyttöön. Parin kolmen yrityksen tiedetään jo käyttävän tätä, mutta nimistä ei kuitenkaan ole tietoa.
Osa 3 antaa suositukset pankkiyhteyksien turvaamisesta asiakkaan luona.
PATU perustuu ISO 8730-8732 ja ISO/DIS 10126 pankkitoimistandardeihin, jotka määrittelevät mm. MAC -tarkistusmenetelmän, jota käytetään todentamiseen ja eheyden tarkastamiseen. Lisäksi nojataan ANSI X3.92-1981 (DEA) ja ANSI X3.106-1983 (Modes of Operation) standardeihin.
MAC lasketaan viestistä 8-tavun lohkoissa käyttäen DES-algoritmia kerta-avaimella (satunnaisluku) seuraavasti:
T[1] = DES(DATA[1])
FOR (I = 2; I < LEN(DATA) + 1; I++) {
T[I ] = DES(T[I - 1] + DATA[I])
}
Data käydään siis läpi kahdeksan tavun lohkoissa (paddataan 0:lla, mikäli viestin pituus ei ole kahdeksalla jaollinen) ja viimeiseksi saatu tulos on viestin tiiviste, joka sijoitetaan turvasanomaan, josta myös lasketaan MAC (tarkiste) käyttöavainta käyttäen. Käytetty kerta-avain kulkee myös turvasanomassa, kryptattuna käyttöavaimella.
PATU perustuu siis DES-algoritmiin. Huonona puolena on, että nykyään DES:iä ei enää pidetä turvallisena algoritmina. Väistämättä PATU:a on kehitettävä siten, että todentaminen tehdään turvallisella salausmenetelmällä esim. 1024 bittisellä RSA:lla.
Huomioitavaa on myös se, että tiedon esitystapana ei käytetä EDIFACT:ia, mutta pankki pyrkii antamaan oman tunnuksensa ja asiakastunnuksen OVT-tunnusstandardin SFS 5748 mukaisena.
AUTACK (ISO 9735 osa 6) määritelmään perustuva todennus ja kuittaus on käytössä muualla maailmassa, ainakin jossain määrin. WWW-sivuilta löytyi muutama pointteri ja maininta jo olemassa olevista järjestelmistä:
Concord Eracom Nederland B.V. tekemä SCORE (crypto toolkit) on integroitu (valmistajan antaman tiedon mukaan, http://www.euro.net/concord/score.html/):
Toinen valmistaja COST Computer Security Technologies (http://www.dsv.su.se/~sead/cost-edi.html/) tarjoaa seuraavaa:
Paketti syö EDIFACT-syntaksin mukaisia tiedostoja ja tuloksena standardin mukaista Secure EDIFACT tavaraa tai ainakin näin väitetään, tietoa oli niukalti saatavilla. Yhtään referenssiä ei ainakaan ollut tarjolla.
WWW tullee näyttelemään merkittävää roolia elektronisessa vähittäiskaupassa. Seurauksena on tietoverkkojen liikennemäärien räjähdysmäinen kasvu. EDI/OVT:n puolestapuhujat toivovat EDIFACT-standardin lyövän nyt itsensä läpi eräänlaisenä elektronisen kaupan 'backbone':na, runkona massivisille tiedonsiirtomäärille. EDIFACT-standardi on sen verran raskas, että se tuskin tulee yksittäiselle käyttäjälle asti, mutta se ei vastanne tarkoitustakaan.
Joka tapauksessa OVT/EDI on saavuttanut vankan aseman yhteiskunnassamme ja tietoturvan lisäys on välttämätöntä sen aseman säilyttämiseksi. Standardin esitys ei välttämättä mene heti läpi, mutta uskomme, että synergiaa löytyy ja palikat saadaan nopeasti kasaan.
OVT:n tietoturvan osalta elämme lapsenkenkä -vaihetta. Ensimmäiset askeleet on otettu, kengät hiertävät eivätkä tunnu vielä hyviltä. Niitä ei tekisi mieli käyttää, mutta maaperä alkaa olla sen verran vaikea, että käynti on tuskaista ilman niitä.
Vaaditaan paljon työtä, ennenkuin meillä on jokapäiväisessä käytössä määritellyt tietoturvamekanismit. Olemassa olevia OVT-järjestelmiä on käytössä todella paljon ja turvapalveluiden integrointi ei ole ilmaista. Kukapa haluaa tuhlata rahaa sellaiseen, mistä ei saa selvää ja välitöntä hyötyä, mutta kun kaikki olemassa olevat riskit on kartoitettu ja sisäistetty, uskon äänen kellossa vaihtuvan.
PATU-järjestelmäkuvaus, Osa 1, v1.2, 18.3.1994
PATU-järjestelmäkuvaus, Osa 3, v1.1, 13.1.1993
RSA DATA Inc., WWW-sivut (http://www.rsa.com/)
The European Public Sector, EDI Newsletter, October 1994, Issue 4
The European Public Sector, EDI Newsletter, December 1994, Issue 5
The European Public Sector, EDI Newsletter, March 1995, Issue
6
TRADE/WP.4/R.1026, 7 February 1994
TRADE/WP.4/R.1026/Add.1, 7 February 1994
TRADE/WP.4/R.1026/Add.2, December 1993
TRADE/WP.4/R.1026/Add.3, 18 February 1994
TRADE/WP.4/R.1026/Add.4, MIG, 10 December 1993
UN/EDIFACT WD 9735-5, 1995
UN/EDIFACT WD 9735-6, 1995
UN/EDIFACT WD 9735-7, 1995