Autor |
Beitrag |
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: Do 05.01.17 18:49
Hallo liebes Entwickler Team,
wie kann man Updates sicherer machen?
Vorab, bis jetzt funktioniert der Update Prozess so: Auf einem Server wird eine Textdatei mit der neuesten Versionsnummer gehostet. Das Programm lädt sich diese runter und vergleicht den Inhalt mit der jetzigen Programmversion. Gibt es Unterschiede, wird ein ZIP heruntergeladen und installiert. Fertig.
Jetzt kann ja ein Angreifer die den ZIP abfangen, manipulieren und die anderen PCs installieren dann den modifizierten ZIP.
Wie kann man das sicherer machen? Ich dachte an einen Schlüssel, mit dem die Text Datei signiert ist und an einen Gegenschlüssel, den das Programm hat. Wenn diese beiden übereinstimmen, wird der ZIP heruntergeladen.
Kann mir mal jemand sagen, was er davon hält und über welchen Sicherungsalgorithmus kann ich das machen? Sha256?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
Ralf Jansen
Beiträge: 4706
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Do 05.01.17 19:06
Hatten wir das Thema Codesigning nicht gerade erst?
Besorg die ein entsprechendes Zertifikat und signiere damit deinen Installer. Ob du noch eine spezielle clientseitige Prüfung brauchst musst du selbst wissen aber ich finde die Zweifelhaft. Den kann man ja vermutlich auch so runterladen für zum Beispiel eine Erstinstallation ohne das das jetzt deine individuelle Updatefunktion aus deiner Anwendung verwendet wird. Es gibt dann keinen clientseitigen Code der da was prüfen könnte. Man kann den User nur anleiten wie er die Signatur selbst prüft wenn ihm das wichtig ist oder man verläßt sich auf die Signaturprüfung von Windows selbst.
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: Do 05.01.17 19:13
Achso, aber ich habe keine Website gesehen, wo man ein kostenloses Zertifikat bekommt. Und ich kann jetzt nicht nochmal Geld in sowas reinstecken :/
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
Ralf Jansen
Beiträge: 4706
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Do 05.01.17 19:36
Dann denke ich wirst du keine sichere (automatische) Downloadmöglichkeit hinbekommen.
Ohne asymmetrischen Schlüssel der von einer glaubwürdigen Stelle als glaubwürdig zertifiziert ist, wäre eine andere Möglichkeit denn Hash des bekannten sicheren Downloads zu veröffentlichen. Sowas schien dir ja auch vorzuschweben. Das geht aber nicht automatisch. Wenn du oder dein User dem Kanal nicht trauen über denn du den Download bekommst warum solltest man dem Kanal trauen um den Hash zum User zu bringen? Das mit dem Hash funktioniert nur einigermaßen wenn da ein 2.ter Kanal mit Aktivität vom User aus besteht. (2 verschieden Wege gleichzeitig passend zu hacken ist schwer) Dazu könntest du die Hashes der bekannten Sicheren Dateien auf deiner Webseite veröffentlichen. Dann muss aber der User selbst aktiv werden und sich diesen Hash aktiv von deiner Webseite holen und gegen deine Anwendung prüfen und zwar mit einem Hashing-Tool das nicht zu deiner Anwendung gehört. Denn wenn du dem Download nicht traust (sonst wärst du nicht hier und würdest diese Frage nicht stellen ) gibt es keinen Grund einem Tool aus gleicher Quelle zu trauen.
Heißt:
- Hash auf die Webseite packen
- Dort dokumentieren wie man den Hash prüft (wo man ein passendes Tool bekommt und am besten wie man das verwendet)
- In der Anwendung maximal eine Anleitung geben wie man manuell die Sicherheit des Downloads prüft aber nichts automatisch machen da automatisch nicht wirklich möglich ist bzw. nur Scheinsicherheit wäre
|
|
jfheins
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: Do 05.01.17 23:01
Ralf Jansen hat folgendes geschrieben : | Dann denke ich wirst du keine sichere (automatische) Downloadmöglichkeit hinbekommen. |
Naja, es ist noch nicht aller Tage Abend
Ralf Jansen hat folgendes geschrieben : |
- Hash auf die Webseite packen
- Dort dokumentieren wie man den Hash prüft (wo man ein passendes Tool bekommt und am besten wie man das verwendet)
- In der Anwendung maximal eine Anleitung geben wie man manuell die Sicherheit des Downloads prüft aber nichts automatisch machen da automatisch nicht wirklich möglich ist bzw. nur Scheinsicherheit wäre |
Es ist in der Tat schwierig, die Erstinstallation abzusichern. Aber Updates sollten sich ja machen lassen.
Dazu einfach ein asymmetrisches Schlüsselpaar erzeugen und den public-Key im Programm hinterlegen.
Für ein Update muss man dann das zip-Archiv signieren. Das heißt, eine Checksumme (z.B. sha256) wird mit dem privaten Schlüssel verschlüsselt. Der Updater lädt nun das zip und die Signatur getrennt runter und kann schließlich das zip wieder hashen, die Signatur entschlüsseln und beides vergleichen.
Da kann man auch problemlos seine eigene CA aufmachen und muss kein Geld ausgeben. Aber es sind dann halt nur die Updates abgesichert.
|
|
Holgerx
Beiträge: 63
Erhaltene Danke: 27
Win95 - Win11 / MSServer2000 - MSServer2019
Delphi 6pro / XE4
|
Verfasst: Fr 06.01.17 05:51
Hmm..
Also der TE hat die Download und Prüfroutinen selber geschrieben, braucht also kein externes Tool zum Prüfen.
Ich denke, vereinfacht würde ich das so machen:
- Von Update-Datei einen Hash erzeugen
- Diesen Hash verschlüsselt in die Info-Datei
- Client lädt die Info-Datei und dekodiert den HASH
- Client lädt die Update-Datei und vergleicht den Datei-Hash
- Wenn übereinstimmend, dann alles OK
Durch das verschlüsseln des Hashes ist das Problem reduziert, das sowohl die Update-Datei, wie auch die Info-Datei bearbeitet wurden.
Die Keys für die Verschlüsselung kennst nur Du und dein Download-Tool. Somit kann ein Dritter nicht unbemerkt deine Update-Datei bearbeiten, ohne dass Du es merkst..
Wie gesagt, nur eine vereinfachte Idee, ohne Zertifikate.
Um das ganze noch sicherer zu machen, könntest Du bei einem Update auch einen neuen Key mitschicken, welcher dann für den nächsten Download gültig ist.
Dann müssen die Updates nur in einer festen Reihenfolge geladen und eingespielt werden.
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: Sa 07.01.17 16:58
Die Idee von Holgerx gefällt mir schon ganz gut. Aber angenommen in dem Quellcode ist ein Hash, man lädt sich das Update herunter und der andere Hash stimmt mit diesem überein. Aber wenn man das Programm dekompilliert, kommt man ja auch an den Hash, oder nicht?
Und wenn man eine Version bsp überspringt, kann es doch dann auch zu Problemen kommen, oder nicht?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
Ralf Jansen
Beiträge: 4706
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Sa 07.01.17 17:16
In deinem Programm ist kein Hash der zu dekompilieren ist. Und wenn es so wäre wäre es auch nicht schlimm ein Hash ist kein Geheimnis. Deine Frage zeigt das dir scheinbar nicht ganz klar ist was ein Hash ist. Du solltest da mal nachforschen und dir denn Unterschied zwischen einem Verschlüsselungsverfahren und einem Hashingverfahren klar machen. Hashing ist nicht verschlüsseln.
Die Idee von HolgerX bringt dich meiner Meinung nicht weiter. Er möchte das du nicht nur das Update sondern auch den Hash runterlädst. Aber wenn man dem Kanal über den man das Update bekommt nicht traut wieso sollte der Kanal vertrauenswürdig sein wenn man über diesen Weg auch den Hash holt? Wenn das eine zu hacken ist wird man einfach auch beides hacken können. Zu einem falschen Update bekommst du also auch einfach einen passenden falschen Hash. Denn Hash mit runterzuladen hilf vielleicht einen kaputten Dateidownloader zu entlarven aber das Verfahren hält keinen potentiellen Angreifer auf. Es hilft ein wenig 2 dezidiert unterschiedliche Wege zu benutzen um an Hash und Update zu kommen. Letzlich finde ich das Verfahren dann aber immer noch fraglich.
Da ist die Idee von jfheins schon deutlich besser. Ich persönlich mag das nicht weil was hilft es wenn ich den Update einer Anwendung absichere das zu dieser Absicherung ein bestimmtes Mitwirken der bisherigen Installation der Anwendung braucht ich die Erstinstallation aber schon gar nicht so hinbekommen habe das diese Erstinstallation sicher (aka unverändert) ist.
|
|
Holgerx
Beiträge: 63
Erhaltene Danke: 27
Win95 - Win11 / MSServer2000 - MSServer2019
Delphi 6pro / XE4
|
Verfasst: Sa 07.01.17 19:03
Hmmm..
Ralf Jansen hat folgendes geschrieben : |
Die Idee von HolgerX bringt dich meiner Meinung nicht weiter. Er möchte das du nicht nur das Update sondern auch den Hash runterlädst. Aber wenn man dem Kanal über den man das Update bekommt nicht traut wieso sollte der Kanal vertrauenswürdig sein wenn man über diesen Weg auch den Hash holt? Wenn das eine zu hacken ist wird man einfach auch beides hacken können. Zu einem falschen Update bekommst du also auch einfach einen passenden falschen Hash. Denn Hash mit runterzuladen hilf vielleicht einen kaputten Dateidownloader zu entlarven aber das Verfahren hält keinen potentiellen Angreifer auf. Es hilft ein wenig 2 dezidiert unterschiedliche Wege zu benutzen um an Hash und Update zu kommen. Letzlich finde ich das Verfahren dann aber immer noch fraglich.
|
Und deshalb sollte der HASH verschlüsselt sein, und die Keys für die Entschlüsselung kennen nut CLient und der Ersteller des Original-Updates.
Somit können BEIDE Dateien abgefangen werden, aber wenn der Hacker nicht den Key kennt, dann kann er HASH-Werte erzeugen, wie er will, der Client akzeptiert das Update nicht..
Ist, wie ich geschrieben hatte ein 'vereinfachtes' Verfahren.
Wenn noch dazu die Updates von einem Server per z.B. HTTPS heruntergeladen werden (mit Authentifizierung) dann ist auch dies wieder eine weitere Absicherung.
Dies kann zwar immer weiter auf die Spitze getrieben werden, aber wenn der User mit irgendwelchen Dritttools irgendwelche Zertifikate prüfen soll, bevor er diese Updates installiert, dann ist das aus meiner Sicht Overkill.
Dann brauche ich auch gar kein Online-Update und der User bekommt das Update per z.B. CD von mir in die Hand gedrückt..
So spare ich mir den ganzen Aufwand..
|
|
jfheins
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: Sa 07.01.17 21:54
Der wirklich "gute" Trick ist aber ja die asymetrische Verschlüsselung. Ich nehme mal an, du meintest hier:
Holgerx hat folgendes geschrieben : | - Von Update-Datei einen Hash erzeugen
- Diesen Hash verschlüsselt in die Info-Datei
- Client lädt die Info-Datei und dekodiert den HASH
- Client lädt die Update-Datei und vergleicht den Datei-Hash |
eine symmetrische Verschlüsselung. Das Problem daran ist ja, dass jeder der den Updater dekompilieren kann an den Schlüssel bekommt.
Und da das Programm ja als bekannt gilt, ist die Maßnahme wenig sinnvoll.
Zum Einstieg kannst du dir ja mal die Klasse RSACryptoServiceProvider anschauen.
Damit solltest du einSchlüsselpaar erzeugen können, dass du bei die speichern musst. Dann kannst du für ein Update die Methode SignData() aufrufen: msdn.microsoft.com/e...32675(v=vs.110).aspx
In dem Updater gibst du den public Key als XML mit und rufst dann VerifyData() auf.
Bei zip-Dateien kannst du sogar noch Bytes hinter das eigentliche Archiv schreiben. Damit brauchst du keine separate Datei sondern fügst die Signatur einfach an die Datei an. Den Signaturprozess kannst du auch per Powershell aufrufen, wenn du dafür kein eigenes C#-Programm schreiben willst.
|
|
jfheins
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: Sa 07.01.17 22:57
Weil ich gerade Zeit und Interesse hatte, habe ich mal ein Demo-Programm gemacht:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85: 86: 87: 88: 89: 90: 91: 92: 93: 94: 95: 96: 97:
| namespace Test_1 { public partial class Form1 : Form { public Form1() { InitializeComponent(); }
private void button1_Click(object sender, EventArgs e) { using (var rsa = new RSACryptoServiceProvider(2048)) { var privateKey = rsa.ToXmlString(includePrivateParameters: true); var publicKey = rsa.ToXmlString(includePrivateParameters: false);
File.WriteAllText(@"./private.xml", privateKey); File.WriteAllText(@"./public.xml", publicKey); } }
private void button2_Click(object sender, EventArgs e) { var filename = @"./nextUpdate.zip";
var fileContent = File.ReadAllBytes(filename); var rsaKey = File.ReadAllText(@"./private.xml"); byte[] signature;
using (var rsa = new RSACryptoServiceProvider(2048)) { rsa.FromXmlString(rsaKey); signature = rsa.SignData(fileContent, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); }
using (var stream = new BinaryWriter(new FileStream(filename, FileMode.Append))) { stream.Write(signature); stream.Write(signature.Length); } }
private void button3_Click(object sender, EventArgs e) { var filename = @"./nextUpdate.zip";
var fileContent = File.ReadAllBytes(filename);
if (fileContent.Length < 260) { MessageBox.Show("Fehlende Signatur oder unbekannter Algorithmus!", "Signaturprüfung"); return; }
var rsaKey = File.ReadAllText(@"./public.xml"); byte[] signature = null; int signatureLength = 0;
using (var stream = new MemoryStream(fileContent)) { using (var reader = new BinaryReader(stream)) { stream.Seek(-4, SeekOrigin.End); signatureLength = reader.ReadInt32(); if (signatureLength != 256) { MessageBox.Show("Fehlende Signatur oder unbekannter Algorithmus!", "Signaturprüfung"); return; } else { stream.Seek(-4 - signatureLength, SeekOrigin.End); signature = reader.ReadBytes(signatureLength); } } } var contentLength = fileContent.Length - signatureLength - 4;
using (var rsa = new RSACryptoServiceProvider(2048)) { rsa.FromXmlString(rsaKey); var result = rsa.VerifyData(fileContent, 0, contentLength, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); if (result) MessageBox.Show("Signatur erfolgreich verifiziert :-)", "Signaturprüfung"); else MessageBox.Show("Beschädigte oder fehlerhafte Signatur!", "Signaturprüfung"); } } } } |
Du musst dann nur aufpassen, dass du gut auf den privaten Schlüssel aufpasst. Wenn du den verlierst (= vernichtet wird), musst du ein neues Schlüsselpaar generieren und alle Update-Prüfungen werden Alarm schlagen. Wenn der private Schlüssel entwendet wird, dann ist der Updater wieder unsicher.
Sag Bescheid, wenn was unklar ist
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: Sa 07.01.17 23:46
Bei mir wird Sha256 und Pkcs1 unterkringelt, da irgendein Assembly Verweis fehlt. Welchen muss ich da hinzufügen?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
jfheins
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: So 08.01.17 00:31
Laut der Doku-Seite:
Zitat: | Namespace: System.Security.Cryptography
Assembly: mscorlib (in mscorlib.dll) |
Ist das schon drin.
Aber ich glaube, die Typen gibt es erst mit .net 4.6. Du müsstest dann das Zielframework anpassen. (Rechtsklick auf das Projekt, Eigenschaften, Zielframework)
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: So 08.01.17 12:42
Ah okay. Vielen Dank, dass funktioniert.
Aber ich habe nun noch ein paar Verständnis Fragen:
1) Wenn ich nun einen neuen Update ZIP habe, den muss ich ja dann auswählen, damit der Algorithmus diesen signiert. Die Methode von Button3 muss ja dann in jedes Clienten Programm?
2) Wenn ich mehrere unterschiedliche Projekte habe, haben die dann unterschiedliche Schlüssel? Also denkt sich die Klasse dann zufällige Schlüssel aus? Und dann brauche ich ja unterschiedliche Ordner mit den unterschiedlichen Schlüsseln, oder? Und den public Key muss ich ja dann im ZIP mitliefern, oder?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
jfheins
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: So 08.01.17 14:12
Csharp-programmierer hat folgendes geschrieben : | Ah okay. Vielen Dank, dass funktioniert.
Aber ich habe nun noch ein paar Verständnis Fragen:
1) Wenn ich nun einen neuen Update ZIP habe, den muss ich ja dann auswählen, damit der Algorithmus diesen signiert. Die Methode von Button3 muss ja dann in jedes Clienten Programm? |
Ja, Button 2 ist quasi das Programm bei dir auf dem Rechner (bevor du das Update veröffentlichst) und der Code aus Button 3 ist in jedem Client.
Csharp-programmierer hat folgendes geschrieben : | 2) Wenn ich mehrere unterschiedliche Projekte habe, haben die dann unterschiedliche Schlüssel? Und dann brauche ich ja unterschiedliche Ordner mit den unterschiedlichen Schlüsseln, oder? |
Können haben, muss aber nicht. Wenn man Geld bezahlen muss, lässt man sich i.d.R. ein Zertifikat pro "Firma/Herausgeber" ausstellen. Wenn du jedem Projekt einen eigenen Schlüssel gibst, wird es bei dir etwas unübersichtlicher.
Csharp-programmierer hat folgendes geschrieben : | Also denkt sich die Klasse dann zufällige Schlüssel aus? |
Ja, der Konstruktor generiert ein neues, zufälliges Schlüsselpaar. Du solltest das aber nur einmal generieren und dann speichern.
Csharp-programmierer hat folgendes geschrieben : | Und den public Key muss ich ja dann im ZIP mitliefern, oder? |
Auf keinen Fall! Der public-Key muss bereits im Programm vorhanden sein. Ein Angreifer, der das zip austauschen kann, könnte ja sonst einfach seinen Schlüssel rein tun.
Deshalb sichert das ganze auch nur den Update-Mechanismus. Die Erstinstallation bringt den public-Key auf den Rechner und der Updater prüft, dass alle zukünftigen Updates zu diesem Schlüssel passen.
Du kannst natürlich ein Update herausbringen, welches den Schlüssel austauscht. Dann wäre in dem zip ein neuer public-Key, signiert wäre es aber noch mit dem alten Schlüssel.
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: So 08.01.17 14:53
Ah okay.
Für 2017 habe ich mir vorgenommen, Code nicht nur einfach abzuschreiben sondern auch zu verstehen, was da passiert.
Wenn ein Programm nun nach Updates sucht, wird ja die Textdatei mit der neuesten Versionsnummer vom Server heruntergeladen. Da muss ich ja noch nichts verschlüsseln. Für die Installation des neuen Updates brauche ich ja noch ein 2. Programm, den Updater. Und dieser Updater löscht dann das alte Programm, lädt sich den ZIP runter, kontrolliert die Signierung und installiert die Anwendung demnach. Aber wenn ich dem Updaten den Public Key mitgebe, kann ja ein Angreifer das Programm dekompillieren und so an den Schlüssel kommen und wenn der den Schlüssel hat, kann er ja auch den ZIP so signieren, oder habe ich da einen Denkfehler?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
Ralf Jansen
Beiträge: 4706
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: So 08.01.17 17:41
Zitat: | Ah okay.
Für 2017 habe ich mir vorgenommen, Code nicht nur einfach abzuschreiben sondern auch zu verstehen, was da passiert. |
Zitat: | Aber wenn ich dem Updaten den Public Key mitgebe, kann ja ein Angreifer das Programm dekompillieren und so an den Schlüssel kommen und wenn der den Schlüssel hat, kann er ja auch den ZIP so signieren, oder habe ich da einen Denkfehler? |
Der öffentlichen Schlüssel ist kein Geheimnis. Überleg mal wie das klingt wenn du behauptest du möchtest den öffentlichen Schlüssel Geheim halten. Wenn man den Geheim halten müsste warum sollte der dann öffentlicher Schlüssel heißen? Nein mit dem öffentlichen Schlüssel kann ein Angreifer wenig anfangen damit kann er nicht mehr im Sinne deines System verschlüsseln er kann damit nur entschlüsseln. Verschlüsseln geht nur mit dem privaten Schlüsseln und auf den musst du aufpassen und geheim halten.
Um dieses System zu knacken muss beides ausgetauscht werden öffentlicher Schlüssel und privater Schlüssel. Da sind wir dann wieder an dem Punkt das die Erstinstallation nicht geschützt ist und somit der Angriff veränderter Client und veränderter Download(Update) noch besteht.
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: So 08.01.17 19:47
Okay, ich habe gerade einen großen Denkfehler. Angenommen der Hashwert ist xxxxx. Dann ist der ZIP Ordner mit xxxxx signiert und in der Anwendung ist der public key xxxxx. Wenn ein Angreifer jetzt das Programm dekompilliert, bekommt er das xxxxx. Jetzt kann er ja den ZIP abfangen, sein Schadprogramm dort reinmachen und den neuen ZIP mit xxxxx signieren, jetzt denkt ja das Programm, dass sei ein signiertes Update und es wird installiert, oder verstehe ich das vollkommen falsch?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
Ralf Jansen
Beiträge: 4706
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: So 08.01.17 20:28
Zitat: | und den neuen ZIP mit xxxxx signieren |
Woher sollte er dafür denn privaten Schlüssel haben? Er hat nur den öffentlichen. Zum signieren braucht es aber den privaten Schlüssel. Mit dem öffentlichen kann man (mehr oder weniger) nur prüfen.
|
|
Csharp-programmierer
Beiträge: 696
Erhaltene Danke: 10
Windows 8.1
C# (VS 2013)
|
Verfasst: So 08.01.17 20:41
Aber durch den privaten Schlüssel kommt doch ein Hash raus, der bsp xxxxx ist, oder?
_________________ "Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein
|
|
|