Vill du vara del av diskussionerna i forumet, ställa frågor eller hjälpa andra? Registrera dig här!

Hur få till säker filverifikation vid nätöverföring?

Trädvy Permalänk
Medlem
Registrerad
Sep 2017

Hur få till säker filverifikation vid nätöverföring?

Jag tycks ha fastnat i mitt sätt att tänka gällande filverifikation. Kan behöva hjälp att förstå.

Filverifikation, som jag tänker mig, är att skicka dels t.ex. 5 filer i sig, men även skicka en textfil som innehåller checksumman för alla förstnämna 5 filerna. På så sätt kan inte t.ex. en elak man-in-the-middle manipulera saker och ting, plus att det kan avslöja filkorruption m.m.

Så sägs det mig. Eller rättare sagt, så vill jag få till det.

Men sanningen är ju den att en man-in-the-middle kan mycket väl öppna en av dom 5 filerna, ändra lite i filen, spara den, och sen analysera fram en ny signatur för filen och byta ut den ursprungliga hash-signaturen som finns i "checksummor"-filen, mot den nya hash-signaturen. Och sen skicka vidare alltsammans.

På så sätt kommer ju inte mottagaren av filerna att märka att en av filerna är manipulerad. Och eftersom alla hash stämmer vid kontroll så finns ju inget mer att diskutera, tänker han. Då spelar det ju heller ingen roll om man kör med det 'säkra' SHA-3 eller det 'osäkra' SFV. Det är endast om avsändaren och mottagaren jämför hashet för varje fil eller mapp, som såna problem upptäcks. Och hur ofta gör man det?

Tänker jag rätt här?

Och om jag tänker rätt, vilka sätt finns det att säkerställa att dom filer som tags emot alltid kan verifieras som identiska med originalet, och kan motstå även manipulations- och andra sabotage-försök?

Tack

Trädvy Permalänk
Medlem
Plats
::1
Registrerad
Feb 2014
Skrivet av Dooley:

Jag tycks ha fastnat i mitt sätt att tänka gällande filverifikation. Kan behöva hjälp att förstå.

Filverifikation, som jag tänker mig, är att skicka dels t.ex. 5 filer i sig, men även skicka en textfil som innehåller checksumman för alla förstnämna 5 filerna. På så sätt kan inte t.ex. en elak man-in-the-middle manipulera saker och ting, plus att det kan avslöja filkorruption m.m.

Så sägs det mig. Eller rättare sagt, så vill jag få till det.

Men sanningen är ju den att en man-in-the-middle kan mycket väl öppna en av dom 5 filerna, ändra lite i filen, spara den, och sen analysera fram en ny signatur för filen och byta ut den ursprungliga hash-signaturen som finns i "checksummor"-filen, mot den nya hash-signaturen. Och sen skicka vidare alltsammans.

På så sätt kommer ju inte mottagaren av filerna att märka att en av filerna är manipulerad. Och eftersom alla hash stämmer vid kontroll så finns ju inget mer att diskutera, tänker han. Då spelar det ju heller ingen roll om man kör med det 'säkra' SHA-3 eller det 'osäkra' SFV. Det är endast om avsändaren och mottagaren jämför hashet för varje fil eller mapp, som såna problem upptäcks. Och hur ofta gör man det?

Tänker jag rätt här?

Och om jag tänker rätt, vilka sätt finns det att säkerställa att dom filer som tags emot alltid kan verifieras som identiska med originalet, och kan motstå även manipulations- och andra sabotage-försök?

Tack

Börjar vi tänka så så blir det att skicka de olika filerna på olika sätt, ex skicka filerna över internt men skicka checksummorna över ex posten. Det absolut bästa skulle vara att göra det fysiskt eller muntligt över telefon. Ska du använda fysiskt post så kan du ju antigen skicka ett flash minne eller skriva ut dom fysiskt på ett papper.

Du skulle även kunna kryptera filerna med ett bra lössen, alt PGP.

Trädvy Permalänk
Medlem
Registrerad
Sep 2017
Skrivet av InaneG:

Du skulle även kunna kryptera filerna med ett bra lössen, alt PGP.

Jag läste på och lärde mig om hash collisions. Jag trodde man använde 'säkrare' hash-metoder typ SHA3, jämfört med SFV, därför att SHA3 inte gick att manipulera - åtminstone inte i närheten lika lätt. Men jag upptäckte att det är ju bara göra nytt hash helt och håller och byta ut det ursprungliga. Så då måste jag missförstått säkerhetsaspekten i att använda mer sofistikerade hash metoder.

Trädvy Permalänk
Hedersmedlem
Registrerad
Jul 2001

Det du gör förslagsvis när du ska distribuera en fil är att du lägger upp hashen på en sida som du har full kontroll över, sen kan du låta mer eller mindre pålitliga mirrors serva själva filen, utan att det behöver råda några tvivel om ifall filerna blivit manipulerade. Att bara lägga med en hash tillsammans med filerna och sprida allt via någon skum källa är som du säger inte särskilt klyftigt om man gör det för att skydda mot manipulation, då handlar det mer om att kunna verifiera att inga fel smugit in vid överföringen.

Skickades från m.sweclockers.com

es en zp rz lw ho wc az em sc

Trädvy Permalänk
Medlem
Plats
örebro
Registrerad
Okt 2001

Det du gör är att du använder ett certifikat och signerar med.

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007

@Dooley: Grejen med osäkra hashalgoritmer är att någon kan skapa en illvillig fil som har samma hash som den riktiga filen. En vanlig användning av hash är ju t.ex. olika typer av nedladdningar från nätet, där en checksum för en fil anges direkt på webbsidan för att den som laddar ned filen ska kunna verifiera att den är korrekt. En osäker hashalgoritm kan då tillåta någon att byta ut filerna på en filserver till andra filer med samma checksum, utan att behöva ändra på webbsidan som länkar till filerna.

Man har ju dock lite samma problem där, hur vet man att webbsidan man tittar på visar rätt checksum? Men om du är under attack från en man-in-the-middle som är kapabel att byta ut både checksummor på sidor du tittar på samt filer du laddar ner så har du troligtvis betydligt större problem att oroa dig över.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Apr 2013
Skrivet av Dooley:

Jag tycks ha fastnat i mitt sätt att tänka gällande filverifikation. Kan behöva hjälp att förstå.

Filverifikation, som jag tänker mig, är att skicka dels t.ex. 5 filer i sig, men även skicka en textfil som innehåller checksumman för alla förstnämna 5 filerna. På så sätt kan inte t.ex. en elak man-in-the-middle manipulera saker och ting, plus att det kan avslöja filkorruption m.m.

Så sägs det mig. Eller rättare sagt, så vill jag få till det.

Men sanningen är ju den att en man-in-the-middle kan mycket väl öppna en av dom 5 filerna, ändra lite i filen, spara den, och sen analysera fram en ny signatur för filen och byta ut den ursprungliga hash-signaturen som finns i "checksummor"-filen, mot den nya hash-signaturen. Och sen skicka vidare alltsammans.

På så sätt kommer ju inte mottagaren av filerna att märka att en av filerna är manipulerad. Och eftersom alla hash stämmer vid kontroll så finns ju inget mer att diskutera, tänker han. På så sätt spelar det ju ingen roll om man kör med det 'säkra' SHA-3 eller det 'osäkra' SFV. Det spelar ju ingen roll. Det är endast om avsändaren och mottagaren jämför hashet för varje fil eller mapp, som såna problem upptäcks. Och hur ofta gör man det?

Tänker jag rätt här?

Och om jag tänker rätt, vilka sätt finns det att säkerställa att dom filer som tags emot alltid kan verifieras som identiska med originalet, och kan motstå även manipulations- och andra sabotage-försök?

Tack

Det där är intressant och jag har själv provat och fått fram att det går att göra ganska enkelt. Jag antar att du rean vet att för att få fram samma checksumma för en ändrad fil så kräver det en sådan ändring att filen i sig kommer att innehålla totalt skada kod eller oläsbar information.

Så enklaste formen är att använda delad överföring, så som banker gör när dom skickar kreditkort, dvs kortet och koden separat. Sannolikheten att en tjuv får både ditt kreditkort och din kod är minimal, och i den digitala värden är det i princip omöjligt eftersom det inte går att förutse vad som händer på samma sätt som på ett postkontor.

Idén här är att du skapar en textfil med checksumma på filerna du för över. Sedan så skapar du en checksumma på denna fil och sparar i textfilen och döper filen till den nya checksumman. Man kan även lägga till en checksumma på en mening båda vet om men är omöjlig att gissa för utomstående.

Resultatet av detta är att om innehållet ändras i fillistan så stämmer inte filnamnet med checksumman och ändras innehållet i filerna så stämmer inte första checksumman på fillistan.

Skickar du fillistan och filerna separat så är det dessutom extremt svårt för en hackare att gissa rätt resultat.

Server: Fractal design Define R5 | AMD Ryzen 7 1800X 8/16 | ASUS ROG Strix X370-F Gaming | 64GB Corsair @ 3000MHz | ASUS Radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2TB Samsung 850 PRO SSD | 6x Seagate Ironwolf Pro 10TB
WS: Phantex Entoo Elite | AMD Ryzen Threadripper 1950X 16/32 | ASUS Zenith extreme | 128GB G.Skill @ 2400MHz | ASUS Radeon HD7970 | 3x 2TB Samsung 960PRO M.2 | 6x Seagate Ironwolf Pro 10 TB
NEC PA301W 30" @ 2560x1600 | Linux Mint 19.2 Cinnamon

Trädvy Permalänk
Rekordmedlem
Plats
Salstad
Registrerad
Feb 2009

Ditt problem är väl mer av kryptografisk natur för du behöver ju på nått sätt överföra data som kan verifiera att "huvudfilerna" är korrekta utan att någon kan komma åt att manipulera.

Ett system för att kryptera verifieringsfilerna eller hela det stora datapaketet så att man kan garantera de är ok eller inte fungerar alls.

Du kan ju också låta bli att skicka din checksumma och i stället publicera den på nått säkert sätt så den som har filen som ska verifieras själv behöver hämta checksumman i stället för att den följer med i filpaketet som ev manipuleras.

Ryzen 5 2400G, Asus ROG STRIX B350-F Gaming, 500GB Samsung 970EVO NVMe M.2 och en väldig massa masslagring. Seasonic Focus+ Gold 650W, Antec P 180 med Schyte o Sharkoon fläktar via en t-balancer, Tittar på en Acer ET430Kbmiippx 43" 4K
Främre ljudkanalerna återges via Behringer DCX2496, högtalare Truth B3031A, Truth B2092A Har också Oscilloskop, mätmikrofon och en Colorimeter.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Feb 2005

Skillnaden mellan SHA3 och SFV (CRC32) är ju att det är mycket svårare att generera filer som matchar det man ska verifiera med. Med CRC32 är det ju relativt enkelt att faktiskt generera filer som har samma checksumma som de "äkta" filerna och då luras att man har rätt.

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

Många opensource-projekt har parallellt med distrubitionen ofta en hash-summa (eller ofta fler med olika hashalgoritmer) som någon går i god för.

Att göra hashkrock på en lätt modifierad fil gentemot originalet är inte lätt - som nämnt så slutare det ofta med total massaker eller så är det helt korrekt om det skall generera samma checksumma - en liten diskret ändring är alltså oerhört svårt att dölja om man önskar en orörd hash-summa

- Med SHA1 så lyckades man (google) få till 2 pdf med lätt skillnad i för samma SHA1-summa - men det var verkligen inte lätt och det låg många månaders beräkning bakom detta även med nätverk av datorer och krävde en ganska stort stycke (och där man hittade ett sätt att få in en bit stycke med data som inte användes av pdf när det skulle visas upp) med data som var väldigt olika mellan dessa båda pdf för att i slutändan skulle generera samma SHA1-summa

MD5 är lättare att attackera med framgång och det var så man falskeligen 'certifierade' payloaden (skadlig mjukvara) för MS certifieringsrutin för installation av mjukvara i bakgrunden och utan en massa varningsrutor dök upp och som användes av stuxnet (NSA/USA troligen).

Erbjuder man 2 hashar - säg en från SHA2-familjer (som SHA256,SHA512) och en från SHA3-familjen för samma fil/arkiv så är det i stort sett bortom möjlighetens gräns att skapa hash-krock på båda samtidigt med samma lätt modifierade indata.

Trädvy Permalänk
Medlem
Registrerad
Sep 2017

Tackar för all hjälp. Det står nu klart för mig att det här med hashning och verifiering används till betydligt fler användningar än bara verifiera filers integritet, vilket jag tänkte/trodde först.

Skrivet av jensa86:

Skillnaden mellan SHA3 och SFV (CRC32) är ju att det är mycket svårare att generera filer som matchar det man ska verifiera med. Med CRC32 är det ju relativt enkelt att faktiskt generera filer som har samma checksumma som de "äkta" filerna och då luras att man har rätt.

Ja det var det här jag tyckte var lite märkligt. Om man ändå har checksumman där i en textfil, varför gå till hästlängder för att göra en fil som stämmer överens med rådande checksumma. Varför inte bara manipulera en fil, ta fram checksumman för den manipulerade filen, och byta ut den rådande checksumman mot den nya.

Anyway, att verifiera en filsignatur i PGP (eller avarter av PGP) har jag nu förstått är en halv mardröm. Man måste ofta installera ett PGP-paket och sen måste man manuellt verifiera att fingeravtrycket stämmer överens med certifikatet på filen osv osv. Det kommer folk i allmänhet inte att orka med. Om det fanns någon signatur eller certifikat som är lätt att verifiera kanske, så ..

Här fanns flera förslag på alternativ, men det som verkar simplast och jag gillade bäst verkar vara det här:

Skrivet av OldComputer:

... skapar en textfil med checksumma på filerna du för över. Sedan så skapar du en checksumma på denna fil och sparar i textfilen och döper filen till den nya checksumman. Man kan även lägga till en checksumma på en mening båda vet om men är omöjlig att gissa för utomstående.

Resultatet av detta är att om innehållet ändras i fillistan så stämmer inte filnamnet med checksumman och ändras innehållet i filerna så stämmer inte första checksumman på fillistan.

Det har dessutom fördelen att då kan dom checksummorna åtfölja filerna hur mycket och länge som helst, även om dom hamnar på USB-minne, optisk skiva eller gud vet vad, och är inte kopplat till något personligt certifikat eller signatur. Men å andra sidan är det ju bara byta ut hela checksums-filen och ersätta den med något som stämmer överens med även en manipulerad fil. Fasen också.

Trädvy Permalänk
Medlem
Registrerad
Dec 2015

Om du använder dig av TLS (till exempel https på webben) för att föra över filer, eller hasharna för filerna, så har du redan använt dig av ett flertal tekniker (inklusive hashning) för att säkerställa både Confidentiality och Integrity i överföringen. Dessutom så kan du vara relativt säker på att du pratat med rätt motpart genom att du använt dig av Public Key Infrastructure vilket i sin tur innebär användning av digitala certifikat (för server och eventuellt klient).

Svaret på ursprungsfrågan är så klart väldigt lärorik, men om det är ett praktiskt problem du försöker lösa så är det nog redan löst. Genom ovanstående tekniker eller på annat sätt, beroende på det exakta problemet.

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

Unixvärldens 'rsync' använde sig av rätt delikata olika typer av hash för att synka två filträd till exakt lika med ambitionen att skicka över så lite data som möjligt mellan sig för jobbet - var det 3 bokstäver som skilde sig i en jättelik databas så var det bara adresser för dessa och dessa 3 bokstäver som fördes över - typ.

Rsync skapades i en tid där data fördes över via långsamma modem och många överföringsprotokoll som kermit, xmodem etc. hanterade inte redan överförda filer särskilt väl utan ville ladda över hela filen på nytt igen fast skillnaderna kunde vara väldigt små och det var frustrerande när det var enorma filer som fördes över var gång så fort tidsstämpeln för filen skilde sig det minsta och ändå inte kunde garantera att filerna var helt lika när tidsstämpeln inte hade ändrat sig (många filsystems tidstämplar var på hela sekunder som lägsta upplösning) .

Det var Andrew Tridgell som skapade rsync som sin thesis och där använde man Locality-sensitive hashing och Locality-preserving hashing för att hitta punkterna som var lika och vad som skilde sig och meddelade 'andra sidan' som gjorde samma sak på sin del och så kommunicera mellan sig och skickade data och instruktioner som krävdes för att göra filerna _helt_ lika - också verifierad med hash.

Andrew Tridgell är också 'pappa' till Samba (SMB) vilket gör att man nätverksmässigt kopplar ihop Unixvärlden och windows-världen och utan den paketet så vete fasen hur det hade sett ut på nätverkssidan idag - för det var ingen lätt stig att gå och med en Microsoft som motarbetade och rent av sabbade så mycket de kunde under tiden...

Han är också skyldig till varför linux-communityn blev av med gratislicensen hos Bitkeeper bara för att han kikade lite på hur protokollet såg ut och skrev en klient som kunde använda sig av det (om man har reverse engineerat hela SMB-prokollet så kan jag tänka mig att det är lite av 'bad habit' av bara farten när man snubblar över det...) och det hela blev jätteinfekterat med företaget och samarbetet och gratislicensen inte gick att rädda. Linus började jaga en ny leverantör av revisionshanteringssystem och som backup skrev han på några få dagar en egen version med de erfarenheter han hade skaffat sig som förvaltare av linux-kernel och konstant inflöde av patchar hela tiden via mail och hur det skulle jämkas in i källträdet och i det vad som saknades enligt hans tycke - det som sedermera blev... Git - resten är som det heter - historia...

Trädvy Permalänk
Medlem
Registrerad
Dec 2018

@Dooley: Använd PGP för verifikation och kryptering av innehållet om du vill vara "säker".
(Confidentiality and Integrity).

// J

Trädvy Permalänk
Medlem
Registrerad
Sep 2013
Skrivet av Jayal1972:

@Dooley: Använd PGP för verifikation och kryptering av innehållet om du vill vara "säker".
(Confidentiality and Integrity).

// J

Det här är rätt svar. För all del kan man diskutera skillnaden på olika hashalgoritmer, vad HTTPS eller andra typer av krypterings- och integritetskontroller tillför, men svaret på grundfrågan är GPG/PGP.

Jag använder inte GPG/PGP så jag kan inte processen i huvudet, men Jag hittade följande bland mina anteckningar från back in the day.

# Skapa nyckelpar gpg --gen-key # Skapa SHA256SUMS, en fil som innehåller hashvärdena för dina filer sha256sum fil1.txt fil2.txt fil3.txt > SHA256SUMS # Signera SHA256SUMS med din privata nyckel och spara resultatet i SHA256SUMS.sig gpg --output SHA256SUMS.sig --detach-sig SHA256SUMS # Exportera din publika nyckel SIGNATURE.asc gpg --armor --export thomas@example.com > ./SIGNATURE.asc # Överför filerna, SHA256SUMS, SHA256SUMS.sig och SIGNATURE.asc # Verifiera att filernas checksumma överensstämmer med vad som anges i SHA256SUMS sha256sum -c SHA256SUMS # Importera den publika nyckeln gpg --import SIGNATURE.asc # Verifiera att innehållet i SHA256SUMS inte ändrats gpg --verify SHA256SUMS.sig

T

Edit: OBS! Mitt exempel krypterar INTE, utan verifierar bara att filernas innehåll inte förändrats och att signaturen stämmer. Men GPG/PGP kan kryptera också, förstås.