Ero sivun ”Tekniikka/Allekirjoitus” versioiden välillä

Kohteesta DigiWiki
Siirry navigaatioon Siirry hakuun
 
(16 välissä olevaa versiota samalta käyttäjältä ei näytetä)
Rivi 16: Rivi 16:
 
'''Käyttäjällä tulee olla luottamus kolmatta osapuolta kohtaan''', koska allekirjoitus tapahtuu aina palvelussa. Allekirjoitettava sisältö paljastuu palvelun omistajalle ja ylläpidolle. Tämä saattaa vähentää mielenkiintoa allekirjoittaa digitaalisesti jos sisältö on luottamuksellista tai arkaluontoista.
 
'''Käyttäjällä tulee olla luottamus kolmatta osapuolta kohtaan''', koska allekirjoitus tapahtuu aina palvelussa. Allekirjoitettava sisältö paljastuu palvelun omistajalle ja ylläpidolle. Tämä saattaa vähentää mielenkiintoa allekirjoittaa digitaalisesti jos sisältö on luottamuksellista tai arkaluontoista.
  
−
Edelläolevista ongelmista johtuen ei ole ihme, että suomalaisella henkilökortilla ei ole sen olemassaolon aikana vuodesta 1999 lähtien tehty digitaalisia allekirjoituksia mPollux ''DigiSign''-ohjelmistolla sen nimestä huolimatta. Tähän saattaa tulla muutos Suomen ja Viron aloittaessa yhteistyön digitalisaatiossa, jonka yhteydessä virolaiseen [[qDigiDoc]]-ohjelmaan (versio 3.10 ja uudemmat) lisättiin tuki Suomen henkilökortille.
+
Edelläolevista ongelmista johtuen ei ole ihme, että suomalaisella henkilökortilla ei ole sen olemassaolon aikana vuodesta 1999 lähtien tehty digitaalisia allekirjoituksia ''DigiSign''-ohjelmistolla sen nimestä huolimatta. Tähän saattaa tulla muutos Suomen ja Viron aloittaessa yhteistyön digitalisaatiossa, jonka yhteydessä virolaiseen [[qDigiDoc]]-ohjelmaan (versio 3.10 ja uudemmat) lisättiin tuki Suomen henkilökortille.
  
  
Rivi 30: Rivi 30:
  
  
−
=== WWW-selaimien allekirjoitusratkaisuja ===
+
== Web-selaimen allekirjoitusratkaisuja ==
  
−
Vuodesta 2002 lähtien on ollut käytössä eri teknisiä toteutuksia ja niitä on korvattu uudemmilla esimerkiksi ympäröivien ohjelmointirajapintojen ([[Middleware|middleware]], sovellukset) muuttuessa. Pluginit jotka aiemmin käyttivät Netscape rajapinta ([[NPAPI]], ''Netscape Plugin Application Programming Interface'') rajapintaa, on vaihdettu uudempiin jotka käyttävät Googlen kehittämää Chrome selain-API/rajapintaa.
+
Vuodesta 2002 lähtien on ollut käytössä eri teknisiä toteutuksia ja niitä on korvattu uudemmilla esimerkiksi ympäröivien ohjelmointirajapintojen ([[Middleware|middleware]], sovellukset) muuttuessa. Web-selaimen yhteydessä allekirjoitustapahtuma jakautuu kahteen osa-alueeseen:
 +
* palvelimen pyyntöön allekirjoittaa sisällön tiiviste
 +
* päätelaitteen tapaan käsitellä varmenteita ja tehdä allekirjoitus
  
 +
Pluginit jotka aiemmin käyttivät Netscape rajapinta ([[NPAPI]], ''Netscape Plugin Application Programming Interface'') rajapintaa, on vaihdettu uudempiin jotka käyttävät Googlen kehittämää Chrome selain-API/rajapintaa.
  
  
−
'''MPollux DigiSign Client''' on [[Väestörekisterikeskus|Väestörekisterikeskuksen]] tarjoama C-kirjasto joka käyttää Microsoftin [[Minidriver]] ja [[CNG]] rajapintoja eikä toimi Applen Mac OSX, iOS tai Linux -käyttöjärjestelmissä. Microsoftin käyttöjärjestelmissä itse allekirjoitusta ei tehdä erillisellä käyttöliittymällä vaan ratkaisu toteuttaa WWW-palvelimen työasemaan ja kyseistä allekirjoitustapaa toteuttava Web-palvelu lähettää allekirjoituspyynnön http://localhost:xxx URL:lla paikalliseen työasemaan josta tulee HTTP-protokollalla allekirjoitus-hash vastauksena. Mitä allekirjoituksella tehdään, olisi Web-palvelun tarjoajan asia. Toteutustapa on vähintäänkin erikoinen eikä se ole ilmeisesti missään tuotantokäytössä.
+
'''SCS''' (''Signature Creation Service'', [[SCS]]) on [[Digivirasto]]n kehittämä allekirjoitustoteutus joka käyttää henkilökortin tukiohjelmistoa. Tuki SCS-tyyppiselle allekirjoittamiselle löytyy [[DigiSign Client]], [[Google/Android|Android]]-mobiililaitteista ja [[SecMaker]] Net iD ohjelmistosta. (käyttää Microsoftin [[Minidriver]] ja [[CNG]] ?)
−
*[[Tekniikka/MPollux DigiSign Client]]  
+
* [[SCS]]
  
  
Rivi 43: Rivi 46:
  
  
−
'''SCS''' (''Signature Creation Service'', [[SCS]]) on [[Väestörekisterikeskus|Västörekisterikeskuksen]] kehittämä, [[eIDAS]] luottopalveluiden mukainen HTML5-sivuihin tarkoitettu allekirjoituspalvelu joka on toteutettu javascriptillä. Tuki SCS-tyyppiselle allekirjoittamiselle löytyy [[mPollux DigiSign Client]] ja [[SecMaker]] Net iD ohjelmistosta.
+
'''chrome-token-signing''', [[Riigi Infosüsteemi Amet|RIA]]:n kehittämä ja Chromen [[WebExtensionsAPI]] -Javascript-rajapintaa (tuettu useissa selaimissa) käyttävä Chrome, Firefox ja Internet Explorer selaimille. Plugin on nykyään laajassa käytössä Virossa.
−
* [[SCS]]
+
* https://github.com/open-eid/chrome-token-signing/wiki
−
 
 
−
 
 
−
'''chrome-token-signing''', [[Riigi Infosüsteemi Amet|RIA]]:n kehittämä ja Chromen ohjelmointirajapintaa (tuettu useissa selaimissa) käyttävä ja Javascript-rajapinnan tarjoajva plugin Chrome, Firefox ja Internet Explorer selaimille. Plugin on nykyään laajassa käytössä Virossa.
 
−
*
 
  
  
Rivi 55: Rivi 54:
  
  
−
'''Web-eID''' kehitteillä oleva, hwcrypton syrjäyttävä javascript-ohjelmointirajapinta joka toteuttaa W3C:n [[WebCryptoAPI]]-määritykset.
+
'''Web-eID''' kehitteillä oleva, hwcrypton syrjäyttävä javascript-ohjelmointirajapinnan tarjoava plugin joka toteuttaa W3C:n [[WebCryptoAPI]]-määritykset.
 
* [[Web-eID]]
 
* [[Web-eID]]
  
Rivi 62: Rivi 61:
 
Osa allekirjoitusmäärityksistä on pelkkää tekstiä joka tulee tallentaa johonkin (sähköpostin osa, tietokannan solu), osa määrittelee tiedostomuodon jonka voi käsitellä perinteisesti (tallentaa levylle, siirtää liitteenä tai eri tiedostonsiirtoyhteyskäytännöillä, FTP, HTTP, SSH, jne):
 
Osa allekirjoitusmäärityksistä on pelkkää tekstiä joka tulee tallentaa johonkin (sähköpostin osa, tietokannan solu), osa määrittelee tiedostomuodon jonka voi käsitellä perinteisesti (tallentaa levylle, siirtää liitteenä tai eri tiedostonsiirtoyhteyskäytännöillä, FTP, HTTP, SSH, jne):
  
−
* [[XAdES]] [[W3C]] ja ETSI:n määritykset XML:n allekirjoitusta varten.
+
 
−
* [[ASiC]] johon virolainen [[DigiDoc]]-allekirjoitussäiliö perustuu.
+
* [[ASiC]] johon virolainen [[DigiDoc]]-allekirjoitussäiliö perustuu. [[qDigiDoc|qDigiDoc4]]-versio käyttää suoraan ASiC-E-formaattia (Extended).
−
* [[CAdES]] [[IETF]]:n [[CMS]]-viestiformaattien laajennokset allekirjoitusta varten.
+
* [[ETSI]] [[AdES]] format family:
−
* [[PAdES]] PDF laajennokset allekirjoitusta varten.
+
** [[CAdES]] [[IETF]]:n(?) [[CMS]]-viestiformaattien laajennokset allekirjoitusta varten.
 +
** [[JAdES]] JSON muodon allekirjotukset
 +
** [[PAdES]] PDF-laajennokset allekirjoitusta varten.
 +
** [[XAdES]] [[W3C]] ja ETSI:n määritykset XML:n allekirjoitusta varten.
 
* [[S/MIME]] SMTP-muotoisten sähköpostien liitemuotoinen allekirjoitusmuoto.
 
* [[S/MIME]] SMTP-muotoisten sähköpostien liitemuotoinen allekirjoitusmuoto.
 
* [[PGP]] SMTP-muotoisten sähköpostien allekirjoitusmuoto.
 
* [[PGP]] SMTP-muotoisten sähköpostien allekirjoitusmuoto.
Rivi 72: Rivi 74:
 
== Kysymyksiä ja vastauksia ==
 
== Kysymyksiä ja vastauksia ==
 
* Voiko samalla tunnusluvun syötöllä allekirjoittaa useamman kerran koodissa? Jos käyttäjä allekirjoittaa nipun tapahtumia (maksuja/sopimuksia/jne) - tuleeko jokaiselle kysyä tunnusluku erikseen?
 
* Voiko samalla tunnusluvun syötöllä allekirjoittaa useamman kerran koodissa? Jos käyttäjä allekirjoittaa nipun tapahtumia (maksuja/sopimuksia/jne) - tuleeko jokaiselle kysyä tunnusluku erikseen?
 +
 +
== Kritiikkiä ==
 +
* Käyttäjän oikeusturvan kannalta on tärkeää, että hän tietää ja voi olla varma mitä asiakirjoja allekirjoittaessa ja mihin mahdollisesti sitoutuu. Koska allekirjoitus on kaksivaiheinen (tiivisteen laskenta, allekirjoitus), eikä tiiviste ole selkokielinen - muodostuu riski, että käyttäjä allekirjoittaa muuta sisältöä mitä luulee allekirjoittavansa koska allekirjoitettava tiiviste on vaihtunut jossakin vaiheessa. Riski on käytännössä marginaalinen, mutta se on suurempi jos käytetyt ohjelmistot ovat palvelussa eikä käyttäjän hallussa olevassa omassa laitteessa.
  
 
== Katso myös ==
 
== Katso myös ==
 
* [[Allekirjoitus]]
 
* [[Allekirjoitus]]
 +
* [[Allekirjoitus/Tavat]]
 +
* [[Allekirjoitus/Muodot]]
  
 +
[[Luokka:Allekirjoitus‏‎]]
 
[[Luokka:Tekniikka|A]]
 
[[Luokka:Tekniikka|A]]

Nykyinen versio 12. helmikuuta 2022 kello 15.40


Allekirjoitettaessa digitaalisesti tulee käsitellä:

  • missä allekirjoitus tapahtuu:
    • laitteessa joka on täysin käyttäjän hallussa (tietokone, tablet)
    • palvelussa (web-palvelu, palveluväylä)
  • allekirjoituksen muoto
  • mihin allekirjoitus tallentuu

Koska palvelu lähettää allekirjoituspyynnön käyttäjälle, ei ole takeita siitä, että kyseinen palvelu olisi rakennettu vastaanottamaan käyttäjän haluamaa allekirjoitettavaa sisältöä - koska tyypilllisesti web-palvelut ovat räätälöityjä. Voisi siis hyvin olla, että yksittäisen palvelun allekirjoitukset liittyäisivät vain palvelun omaan sisältöön.

Allekirjoitettaessa käyttäjä ottaa yhteyden web-palveluun joka tukee allekirjoittamista ja valitsee sieltä allekirjoitettavan sisällön. Web-palvelu lähettää sisällöstä tiivisteen käyttäjän selaimelle joka välittää sen kortinlukijalle ja kortille - jossa allekirjoitus tapahtuu. Itse allekirjoitus välitetään takaisin web-palveluun joka käsittelee sen kuten palveluun on määritelty.

Käyttäjälle ei jää allekirjoituksesta tiedostoa kuten DigiDoc minkä voisi tallentaa itselleen, koska sellaista ei muodosteta missään vaiheessa. Tämä on ongelmallista viitattaessa allekirjoitettuun sisältöön myöhemmin, tällöin tulee aina olla yhteydessä kyseiseen palveluun - joskin ei ole takeita, että kaikki osapuolet näkisivät samaan allekirjoitukseen palvelussa koska todennäköisesti näkyvyys on tiukasti rajattu. Tämä on keskeistä allekirjoituksen kannalta, koska tarkoitus on nimenomaan todistaa sopimus tms jälkikäteen kolmannelle osapuolelle, kuten tuomioistuimelle. Pahimmassa tapauksessa palvelu tuhoutuu tai poistetaan käytöstä, allekirjoittajalla ei ole tähän mitään kontrollia.

Käyttäjällä tulee olla luottamus kolmatta osapuolta kohtaan, koska allekirjoitus tapahtuu aina palvelussa. Allekirjoitettava sisältö paljastuu palvelun omistajalle ja ylläpidolle. Tämä saattaa vähentää mielenkiintoa allekirjoittaa digitaalisesti jos sisältö on luottamuksellista tai arkaluontoista.

Edelläolevista ongelmista johtuen ei ole ihme, että suomalaisella henkilökortilla ei ole sen olemassaolon aikana vuodesta 1999 lähtien tehty digitaalisia allekirjoituksia DigiSign-ohjelmistolla sen nimestä huolimatta. Tähän saattaa tulla muutos Suomen ja Viron aloittaessa yhteistyön digitalisaatiossa, jonka yhteydessä virolaiseen qDigiDoc-ohjelmaan (versio 3.10 ja uudemmat) lisättiin tuki Suomen henkilökortille.


Tekninen toteutus

Allekirjoittaminen perustuu epäsymmetrisiin avainpareihin joista toinen on julkinen, mahdollisimman monen tietämä ja toinen salainen, vain omistajansa tietämä/hallitsema. Tästä syystä epäsymmetristä avainparitekniikkaa kutsutaan julkisen avaimen tekniikaksi.

Digitaalinen allekirjoittaminen ei käytännön syistä vastaa teknisesti täysin perinteistä käsin tehtyä allekirjoitusta jossa allekirjoitus tehdään itse paperiin jossa asiakirja on, vaan allekirjoitus tehdään sisällön yksilöllisestä tiivisteestä (eng hash) joka edustaa sisältöä. Lakiteknisesti on sama, allekirjoitetaanko koko asiakirjan sisältö vai sitä edustava yksilöllinen tiiviste.

Digitaalisessa allekirjoituksessa on oleellista:

  • miten allekirjoitus tehdään
  • missä muodossa se on ja miten se tallennetaan


Web-selaimen allekirjoitusratkaisuja

Vuodesta 2002 lähtien on ollut käytössä eri teknisiä toteutuksia ja niitä on korvattu uudemmilla esimerkiksi ympäröivien ohjelmointirajapintojen (middleware, sovellukset) muuttuessa. Web-selaimen yhteydessä allekirjoitustapahtuma jakautuu kahteen osa-alueeseen:

  • palvelimen pyyntöön allekirjoittaa sisällön tiiviste
  • päätelaitteen tapaan käsitellä varmenteita ja tehdä allekirjoitus

Pluginit jotka aiemmin käyttivät Netscape rajapinta (NPAPI, Netscape Plugin Application Programming Interface) rajapintaa, on vaihdettu uudempiin jotka käyttävät Googlen kehittämää Chrome selain-API/rajapintaa.


SCS (Signature Creation Service, SCS) on Digiviraston kehittämä allekirjoitustoteutus joka käyttää henkilökortin tukiohjelmistoa. Tuki SCS-tyyppiselle allekirjoittamiselle löytyy DigiSign Client, Android-mobiililaitteista ja SecMaker Net iD ohjelmistosta. (käyttää Microsoftin Minidriver ja CNG ?)


npesteid on RIA:n kehittämä, alkuperäistä Netscape-ohjelmointirajapintaa (NPAPI) käyttävä ja Javascript-rajapinnan tarjoava plugin Firefox ja Internet Explorer selaimille. Plugin näkyy selaimessa Firefox Token Signing nimellä ja sen tiedostonimi on npesteid-firefox-plugin.so. Plugin on korvattu Googlen Chrome-selaimen rajapintaa käyttävällä versiolla 2016-2017 vuosina.


chrome-token-signing, RIA:n kehittämä ja Chromen WebExtensionsAPI -Javascript-rajapintaa (tuettu useissa selaimissa) käyttävä Chrome, Firefox ja Internet Explorer selaimille. Plugin on nykyään laajassa käytössä Virossa.


HWcrypto (Hardware cryptography, hwcrypto) on Martin Paljakin oma projekti, mutta ei vielä (2017/Q2) vastaa täysin chrome-token-signing ominaisuuksia. Projektia ei enää kehitetä vaan sen on korvannut Web-eID.


Web-eID kehitteillä oleva, hwcrypton syrjäyttävä javascript-ohjelmointirajapinnan tarjoava plugin joka toteuttaa W3C:n WebCryptoAPI-määritykset.

Muodot

Osa allekirjoitusmäärityksistä on pelkkää tekstiä joka tulee tallentaa johonkin (sähköpostin osa, tietokannan solu), osa määrittelee tiedostomuodon jonka voi käsitellä perinteisesti (tallentaa levylle, siirtää liitteenä tai eri tiedostonsiirtoyhteyskäytännöillä, FTP, HTTP, SSH, jne):


  • ASiC johon virolainen DigiDoc-allekirjoitussäiliö perustuu. qDigiDoc4-versio käyttää suoraan ASiC-E-formaattia (Extended).
  • ETSI AdES format family:
    • CAdES IETF:n(?) CMS-viestiformaattien laajennokset allekirjoitusta varten.
    • JAdES JSON muodon allekirjotukset
    • PAdES PDF-laajennokset allekirjoitusta varten.
    • XAdES W3C ja ETSI:n määritykset XML:n allekirjoitusta varten.
  • S/MIME SMTP-muotoisten sähköpostien liitemuotoinen allekirjoitusmuoto.
  • PGP SMTP-muotoisten sähköpostien allekirjoitusmuoto.
  • PKCS#7 RSA Security yrityksen kehittämä allekirjoitusmuoto.

Kysymyksiä ja vastauksia

  • Voiko samalla tunnusluvun syötöllä allekirjoittaa useamman kerran koodissa? Jos käyttäjä allekirjoittaa nipun tapahtumia (maksuja/sopimuksia/jne) - tuleeko jokaiselle kysyä tunnusluku erikseen?

Kritiikkiä

  • Käyttäjän oikeusturvan kannalta on tärkeää, että hän tietää ja voi olla varma mitä asiakirjoja allekirjoittaessa ja mihin mahdollisesti sitoutuu. Koska allekirjoitus on kaksivaiheinen (tiivisteen laskenta, allekirjoitus), eikä tiiviste ole selkokielinen - muodostuu riski, että käyttäjä allekirjoittaa muuta sisältöä mitä luulee allekirjoittavansa koska allekirjoitettava tiiviste on vaihtunut jossakin vaiheessa. Riski on käytännössä marginaalinen, mutta se on suurempi jos käytetyt ohjelmistot ovat palvelussa eikä käyttäjän hallussa olevassa omassa laitteessa.

Katso myös

Noudettu kohteesta ”http://digisaatio.fi/mediawiki/index.php?title=Tekniikka/Allekirjoitus&oldid=8213”