arrow_back Hva er sikker nok kryptering av zip og 7zip uttrekk som sendes til depot?

Question

Depot mottar digitalt skapt arkivmateriale gjennom uttrekk av databasesystemer og innlevering av disse. Arkivskaper lager typisk Noark 5 og/eller SIARD-uttrekk som pakkes etter Riksarkivarens forskrift som en .tar fil (typisk med verktøyet Arkade fa Arkivverket). I tillegg må avsender kryptere uttrekket, altså flytte nevnte .tar fil inn i typisk en PKZIP .zip fil eller 7zip fil med passordbeskyttelse (kryptering).

Spørsmålene er da

1. Hvor sikker er en slik kryptering?
2. Hvor langt passord og med hvilke krav til tegnfordeling må vi stille til avsender?
3. Hva skal til for å knekke krypteringen med programvare og datamaskinkraft?
4. Hvor stor risiko er det at avsender tar med info.xml = .xml i kryptert pakke? Da siden denne kan være fritt tilgjengelig og at det er lettere å knekke et zip/7zip passord hvis man har tilgjengelig en av filene i krytert pakke?
5. Hvilke andre alternativer har vi til PKZIP og 7zip pakkerformater?

Punkt 1, 2 og 3 må presiseres pr. pakket standard og undervalg i krypteringen av disse.

How safe can PKZIP-compatible encryption be?
How to Encrypt & Password Protect your Files with 7-Zip

Comments

Skjønte ikke helt hva du du egentlig spør om i punkt 4, ellers svarer Ole helt fornuftig. info.xml fila som ligger ved siden av tar fila, er vel den som heter noe ala "dias-mets.xml" inne i tar fila. Om den pakkes med tar fil eller ikke utgjør ikke noen risiko så lenge arkivskaper beholder sin som original eller "rettskraftig bevis" for tar fila's integritet. Lager ikke arkivskaper AIP, men andre bør den alltid sendes til arkivskaper.

Tenkte du at siden info.xml har en kjent struktur så kan man lettere knekke krypteringen? Værmeldinger var vel med på å knekke enigma koden.  Husker jeg rett var vel enigma en avansert substitusjon kode, tror ikke det hjelper å vite at det ligger en fil med noe kjent struktur inne i en ny pakke, omkapslet med sterk kryptering

---

Det jeg tenker på er.. skal prøve å forklare muntlig UTEN å slå opp i teknikken under som jeg bare har lest overfladisk og ikke programmert mot.

En zip-fil i PKZIP-formatet består av et antall objekter som kan være krypterte, og hovedregelen er at det er ETT passord for kryptering som er brukt for alle objektene. I tilfellet man bruker Arkade 5 for å lage en Innleveringspakke SIP for innsending depot så er jo uttrekket i en <uuid>.tar fil, mens metadata er info.xml som er <uuid>.xml laget i samme katalog som tar-fila.

Ofte leverer uttrekksprodusenten, som også pakker uttrekket i Arkade, med begge disse filene i forsendelsen. Er det sensitivt materiale så putter de typisk både .tar og .xml fila i pakken med ett krypteringspassord. Hvis en "hacker" har fått tak i info.xml via sosial hacking, bla fordi denne filen er offentlig og ikke hemmelig, så vil man da har nøyaktig en av filene i pakken. Da er teorien at å knekke en zip-fil med PKZIP format er vesentlig enklere hvis man har en eksakt kopi av en av filene som er i kryptert zip-fil. Knekker man så koden for den kjente filen, så har man passordet som er det samme da også for den store pakken .tar fila også.

Legger til at forskriften sier at info.xml skal sendes i en annen kanal enn uttrekket .tar fila !

---

All informasjon du har for hånden for å avgrense en «brute force» operasjon på sjekksummen, vil selvsagt korte ned tiden det tar å finne nøkkelen som produserer den samme sjekksummen. Har du deler av passordet, vet posisjonen til symboler i passordet eller lignende, så vil det potensielt korte ned søketiden. En fil på utsiden kan sikkert brukes for samme formål, ved å kryptere den med ulike passord å sammenligne med data i pakken, men jeg tror ikke det vil korte ned tiden det tar å knekke passordet. Jeg tror heller at nøkkeltesting mot sjekksummen (hashen) er mye mer effektivt. Alt som er ment å kunne åpnes igjen, kan også brytes opp - gitt nok tid. Jeg kan selvsagt også ta feil, kryptografi er et veldig stort tema.

Answer 1

Jeg kan bare svare med egne erfaringer.

1. Hvor sikker er en slik kryptering?
   Bruker du anbefalt algoritme (AES-256), så har du lite å bekymre deg for i dag.

2. Hvor langt passord og med hvilke krav til tegnfordeling må vi stille til avsender?
   Jeg anbefaler 32 tegn bestående av [a-Z+ÆØÅ] [0-9] og ["#¤%&/(!)=?@] for svært sensitive data.

3. Hva skal til for å knekke krypteringen med programvare og datamaskinkraft?
   Det er bare å glemme, innen vi har verktøy til å penetrere AES-256 vil innholdet i våre arkiver være foreldet. NSA bruker AES-256 for høyeste sikkerhetsnivå.

4. Hvor stor risiko er det at avsender tar med info.xml = .xml i kryptert pakke? Da siden denne kan være fritt tilgjengelig og at det er lettere å knekke et zip/7zip passord hvis man har tilgjengelig en av filene i kryptert pakke?
   Jeg ser ikke noe problem med dette, men det kan jo være en ide å sende informasjonsfilen på innsiden av forsendelsen (bak kryptering). Vi har jo Informasjon om deponering som jeg vil anta er nok som pakkevedlegg?

5. Hvilke andre alternativer har vi til PKZIP og 7zip pakkerformater?
   Selv mener jeg at det handler mer om hva som er bredt tilgjengelig hos de som skal pakke og motta filene. men 7z og zip er begge gode formater.

Her er mine anbefalinger:

1. Bruk AES-256 som valg i 7zip når du komprimerer tar+info og følg rådene fra NSM for passord.
2. Om du vil sikre mot kompleksitet ved bitråte eller annen korrupsjon bør du velge 7z med "Non-Solid" blokkstørrelse, sånn at alle filer blir lagret separat i filen.
3. Om du ønsker å komprimere, så har jeg fått gode resultater med følgende innstillinger, på store pakker:
   Compression level: Ultra
   Compression method: LZMA2
   Dictionary Size: 1024MB (Når vi snakker store pakker)
   Word Size: 96
   Solid Block Size: 1GB (Dette mener jeg kun egner seg til transportfiler)
   Så mange tråder du kan gi.

Følger du rådene fra NSM og samtidig bruker AES-256 kan du nok vinne i lotto et par tusen ganger før du klarer å gjette passordet gjennom brute force av algoritmen. Den er trygg nok. ZipCrypto er bredt støttet, men er mye svakere enn hva AES-256 er. Om du bruker sistnevnte, må begge parter ha muligheten til å bruke 7zip. Om du vil grave deg ned i hvorfor ZipCrypto er svakere, kan du lese A Known Plaintext Attack on the PKZip Stream Cipher