[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [SIGNATUR] ATP's anvendelse af digital signatur



I sslug.signatur, skrev Thomas Gundel:
>  Som kommentar til diskussionen om hvorvidt brugeren kan f=E5 stj=E5let sin =
> 
>  private n=F8gle og kodeord,
>  vil jeg bem=E6rke, at problematikken er generel for software-baserede=20
>  signaturer.

Nej, det er specifik for java-applet baserede signaturer. (til en hvis
grad). 

>  Dette er i=F8vrigt samme sikkerhedsniveau, som langt de fleste netbanker=20
>  anvender.

Desværre, ja. 

>  Uanset hvordan man vender og drejer det, vil der i en s=E5dan l=F8sning v=
> =E6re=20
>  et stykke software p=E5 ens computer,
>  der f=E5r adgang til den private n=F8gle. Dette kan v=E6re ens e-mail progr=
>  am,=20
>  browser,
>  operativsystem eller som i ATP's tilf=E6lde en kodesigneret Java applet. Om=
> =20
>  man stoler mere p=E5 det
>  ene eller andet program ser jeg som en personlig pr=E6ference. I tilf=E6lde=
>  t=20
>  med en kodesigneret applet, er det i yderste
>  konsekvens underskriveren af koden, man skal stole p=E5 (dvs. ATP i dette=20
>  tilf=E6lde). Hertil kommer selvf=F8lgelig ogs=E5
>  udstederen af certifikatet.=20
>  Stoler man ikke p=E5 ATP, er der nok ikke megen fornuft i at logge ind p=E5=
> =20
>  Folkeb=F8rsen.

Nej og jo. 

Jeg skal ikke stole på nogen for at de skal tage imod min digitale
signatur. Det er her udelukkende ATP der skal stole på TDC som i
øjeblikket formidler OCES. ATP skal stole på at: 

* TDC har verificeret den pågældende bruger godtnok før signaturen er
  blevet udstedt. 

På den grundlag vælger ATP at udlevere oplysninger og effektuere
handlinger på basis af de logininformationer der har været i systemet. 

Brugeren skal dermed ikke stole specifikt på ATP, andet en at stole på
at TDC har lavet et godt nok stykke arbejde med at udlevere
ATP-server-certifikat til ATP og ikke til nogen som helst
svindelvirksomhed. 

Med andre ord, i et normalt _ikke_ java-applet baseret setup, skal du
kun stole på de gængse mekanismer i X509 systemet og ikke på at den der
i dette tilfælde er indholdsudbyder også er en tilstrækkelig god koder.

Ja, jeg stoler betydeligt mere på Mozilla-projektes kode end jeg gør på
en java-applet som jeg kan få en ny kastet i nakken af på ethvert
website jeg kommer hen til. 

Endividere skal dem der har kodet java-appletten have den signeret på en
måde hvor den kan verificeres med en af de rod-certifikater der er kendt
af dit JRE. 

Fordelen ved bankernes system som det har været hidtil er at du her
rigtigt godt forsikret hvis der sker et eventuelt misbrug. Det er ganske
få tusinde kroner du selv kommer til at hæfte for. 

>  Hvis man kigger videre end logonsituationen, vil brugerens private n=F8gle =
>  s=E6dvanligvis ogs=E5 blive anvendt ved underskrivning
>  af aftaler / transaktioner. Da der ikke findes nogen universel=20
>  signeringskomponent,

Din emailklient er da godt hen ad vejen en sådan komponent. Men her har
du desværre ret. Jeg har dog svært ved at se hvorfor man ikke har løst
det, eksempelvis pr. email eller udladt at kunne gøre dette i første
omgang indtil det var blevet standardiseret på en god måde. 

>  vil man under alle omst=E6ndigheder komme ud for, at ens private n=F8gle=20
>  bliver tilg=E5et af et stykke software,
>  som tjenesteudbyderen udvikler eller licensierer (f.eks. CBT Sign Applet=20
>  eller OpenSign).
>  Vil man ud over at skulle stole p=E5 nogen form for software til h=E5ndteri=
>  ng=20
>  af ens private n=F8gle,
>  m=E5 man k=F8be en sikker hardwareenhed som et smart card eller USB token. =
>  Her=20
>  kommer man i=F8vrigt heller=20
>  ikke uden om, at at hardwareproducenten kan have indlagt en bagd=F8r.

Siger du at en hardware-dims løser problemet eller at de pågældende
løsninger ikke virker, hvis du har din digitale signature på en
hardware-dims? 


Jesper

-- 
./Jesper Krogh, sslug@sslug, Jabber ID: sslug@sslug
Danmark har fået sit eget Mozillaforum:
http://forum.mozilladanmark.dk/ eller nntp://news.sslug.dk/mozilladanmark.*



 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 20:34 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *