Mail, kryptering og vedlegg

[HDSoftware]

Hola....

 

Våre kunder har behov for en sikker måte å sende mailer på. Mye av mailene til våre kunder er sensitivt materiale og det blir vedtatt i disse dager lovendringer når det gjelder sending av mail etc. etc.

 

Vi har prøvd å diskuttere litt her på hvordan man kan løse slikt og det er flere scenario som er aktuelle, alt fra kryptering av mail til "online" vedlegg.

 

Det jeg lurer på er om noen har noen tanker på hvordan første alternativ kan gjøres?

 

En god løsning bør være slik at ingen 3rd party software må installeres hos mottaker. Det betyr at mottakeren må kunne bruke Outlook, Express, Whatever til å hente ned mailen sin, men innholdet må kunen krypteres slik at den ikke skal kunen åpnes av uvedkommede. Dette fordi mail kan feilsendes og slikt.

 

Jeg har kikket på ZIP og denne virker veldig grei, men i følge dokumentasjonen på web sidene deres så er denne krypteringen for dårlig og skal vist kunne "dirkes opp" veldig enkelt med rett software.

 

Nå er det jo slik at ZIP også støtter AES kryptering, men det er ikek støttet i Windows.

 

Finnes det andre standarder jeg kan kikke på her?

 

Som hovedregel må dette altså være slik:

Mottaker mottar en mail med ett eller flere vedlegg.

Mottaker har passord for å kunne åpne vedlegget.

Uvedkommede som ikke har passordet skal IKKE kunen åpne vedlegget.

Alt må være støttet i Windows Out of the box.

[GeirGrusom]

Jeg ville sagt at email ikke er en sikker måte å sende sensitiv informasjon på...

[HDSoftware]

du har selvsagt rett i det, men det er ikke noe alternativ å sende pr. snailmail er det vel? Og da er eneste alternativet en online løsning med credentials. Det er selvsagt en måte, men er den noe bedre?

 

Hvisomatte - hvordan ville en mail løsning uansett kunne gjøres så trygg som mulig?

[HDSoftware]

OT: Ser du har noe så morro som VirtualBox i signaturen.....

 

Er litt nysgjerrig for vi er i ferd med å virtualisere hele server parken vår. Vi har vel egentlig gått for MS HyperV, men det er bare fordi vi jeg ikke gidder sette meg inn i Linux. Er VirtualBox et seriøst alternativ her? eller....

[GeirGrusom]

Jeg er ikke kjent med HyperV, men jeg liker ihvertfall VirtualBox svært godt.

 

Men on-topic: Jeg kan ikke tenke på noen løsning som fungerer out-of-the-box...

[nebrewfoz]

Som hovedregel må dette altså være slik:

Mottaker mottar en mail med ett eller flere vedlegg.

Mottaker har passord for å kunne åpne vedlegget.

Uvedkommede som ikke har passordet skal IKKE kunen åpne vedlegget.

Alt må være støttet i Windows Out of the box.

Du kan jo se litt på Sophos Free Encryption.

 

Den kan lage "self-executable" krypterte arkiver, slik at mottakeren bare kjører .exe-filen og gir inn passordet/kryptonøkkelen, og vips er filene i klartekst der.

 

Ulempen er selvsagt at man må sende/motta exe-filer ...

Mange email-systemer blokker disse. (Noen kan lures ved å endre .exe til noe annet ...)

 

Hvis du lemper litt på "out of the box"-kravet og lar mottaker installere programmet på sin maskin, så har både sender og mottaker en enkel måte å håndtere de krypterte arkiv-filene på.

[MailMan13]

Vi har tilsvarende problem for en leveranse. Vi valgte å lage en webløsning der det som er sensitivt kun er tilgjengelig via web.

 

Det går en ukryptert mail til kunden som sier at sånn og sånn dokument er nå tilgjengelig, med link inn i portalen. Der logger kunden inn, i dette tilfellet med BankID, og får tilgang til dokumentene sine og kan laste eller lese dokumentene sine derfra.

 

Om det er en bra eller dårlig løsning kommer selvfølgelig mye an på innholdets art, men for oss var det det beste måten å få "nettbank"-nivå sikkerhet uten å legge for mye ekstra over på klienten.

Endret 10. februar 2010 av MailMan13

[muggsopp]

PGP.

 

Enkelt og greit.

[HDSoftware]

??? PGP???

 

ok. Fant det ut...

 

Men krever ikek dette en installering hos mottakeren? Det er uaktuellt...

[kaffenils]

Jeg tror du skal slite lenge med å finne noen metode som ikke krever noe av mottaker.

 

Skal du kryptere innholdet i mailen så må mottaker ha nøkkelen for dekryptering.

 

Skal du sende en ukryptert mail med link til en websiden som MailMan13 foreslår, så må mottaker ha brukernavn og passord for pålogging.

[HDSoftware]

Brukernavn og passord eller nøkkel er het greit. For det krever ikek noe installasjon. En installasjon medfører ALLTID support. Og i dette tilfellet er det våre kunder som i såfal lmå drive support for sine kunder igjen og det er uaktuellt. Men at våre kunder kan få et ferdig generert passord fra vårt program som de gir til sine kunder er helt akseptabelt.

 

Jeg var inne på å bruke ZIP for dette er jo støttet av Windows Out of the Box. Men ZIP kryptering er etter sigende for dårlig. Nå støtter jo ZIP litt mere moderne kryptering, men ikek i Windows API'et desverre.

 

Vi kom derfor frem til at ZIP i sin enkleste form ikek er tilstrekkelig.

 

Spørs om vi rett og slett havner på en portal løsning her... Egentlig synd. .NET har jo alle former for kryptering innebygget så det burde jo vært null problem for Microsoft å implementere en litt bedre kryptering i ZIP biblioteket sit..

 

 

Ved nærmere ettertanke så er det jo ikke sikkert at våre kunders kunde bruker Windows. Altså er den løsningen uaktuell i utgangspunktet...

Endret 12. februar 2010 av HDSoftware

[kaffenils]

du har jo S/MIME også, men det krever at mottakers mailsystem støtter det, og i tillegg så krever det jobb med å installere private og public nøkler hos mottakere og avsende.

 

.NET har jo alle former for kryptering innebygget så det burde jo vært null problem for Microsoft å implementere en litt bedre kryptering i ZIP biblioteket sit..

Det hjelper jo lite hvis mottakers unzip-progtam ikke støtter den formen for kryptering som du har benyttet.

[HDSoftware]

ja, det er en ide, men son du sier, og som artikkelen sider - problematisk ved installasjon...

[nomore]

Husk det at all den tid uvedkommende har full tilgang på vedleggene så kan de kjøre ganske tunge cracking forsøk. For å få til en sikker løsning mener eg at ingen må få tilgang på vedleggene før de får godkjent tilgang.

 

I tillegg er ikke e-post hverken en sikker eller garantert måte å transportere informasjon på. Det er en billig og rask løsning. Bør ikke behandles som noe annet.

[kaffenils]

Husk det at all den tid uvedkommende har full tilgang på vedleggene så kan de kjøre ganske tunge cracking forsøk. For å få til en sikker løsning mener eg at ingen må få tilgang på vedleggene før de får godkjent tilgang.

 

I tillegg er ikke e-post hverken en sikker eller garantert måte å transportere informasjon på. Det er en billig og rask løsning. Bør ikke behandles som noe annet.

Kryptert med asymmetriske nøkler (lange nok) så skal det noe til å knekke dette. Hvis en er redd for at slikt kan knekkes så bør en ikke sende det elektronisk i det hele tatt. Da er personlig overlevering eneste alternativ.

[nebrewfoz]

Kanskje noe a la YouSendIt kan være en mulig løsning?

[nomore]

Hva om 5000 maskiner i et botnett blir satt til å bruteforce nøkkelen da tro? Tross alt ikke en urimelig tanke i dagens IKT-samfunn.

 

Eg mener følgende punkter bør prioriteres før en løsning blir laget/funnet:

- sikkerhet

- brukervennlighet

- zero-client krav

[kaffenils]

Hvis en frykter slike omfattende brute force angrep så er vel personlig overlevering eneste alternativ.

[MailMan13]

Virker som OP ønsker å tilfredstille ett lovkrav. Ikke lage noe som ikke kan crackes under noen omstendighet.

Endret 12. februar 2010 av MailMan13

[HDSoftware]

Virker som OP ønsker å tilfredstille ett lovkrav. Ikke lage noe som ikke kan crackes under noen omstendighet.

Det stemmer....

 

Problemet er at mange slike lovkrav er ganske patetiske og funnet på av "bedrevitere", men de er nå en gang der og da må man finne på noe som er furnuftig innen for de rammene man har for i det hele tatt å ha et konkurranse dyktig produkt. Om sikkerheten faktisk er noe bedre er et annet spørsmål, men vi vil jo gjerne eterkomme disse kravene.

 

Et annet problem er jo at ofte så sier konkurrentene at "HA! Det støtter vi fullt ut" og så gjør de ike det alikevel, fordi uttalelsen egentlig kommer fra noen som prøver å kjøpe seg tid, samtidig som de vil inn på et marked.

 

Jeg vil ikke føre kundene mine bak lyset på den måten og vil heller presentere noe som faktisk virker og står i henhold til lov krav, og muligens også er litt fremover rettet med tanke på fremtidige krav...