In meiner Firma entwickeln wir ein großes System, bestehend aus mehreren Servern. Das System besteht aus ungefähr 5 logischen Komponenten. Daten werden in XML, MS SQL und SQLite gespeichert. Es ist ein .Net-System (meist), die Komponenten kommunizieren mit WCF und einige benutzerdefinierte UDP. Clients greifen meist über das benutzerdefinierte UDP oder WEB (ASP.NET & amp; Silverlight) auf das System zu.
Der Schutz der Kommunikation ist einfach, einige SSL und einige Sicherheit auf der WCF und wir sind fertig.
Das Hauptproblem, dem wir gegenüberstehen, besteht darin, dass das System auf der Site eines Kunden bereitgestellt werden muss, einem Client, dem wir nicht unbedingt vertrauen. Wir müssen die Daten auf den Servern und die Software selbst durch Reverse Engineering schützen. Beides ist für uns von entscheidender Bedeutung.
Auch brauchen wir einen Kill-Schalter, ich möchte etwas, das die Daten und die Software zerstört, auf Befehl, oder wenn ich für eine bestimmte Zeit nicht zu Hause anrufen kann.
Die Richtung, an die ich dachte, ist die Verwendung von TPM oder etwas Ähnlichem - eine Hardware-Verschlüsselungslösung in Kombination mit einem anderen Dienst, den wir intern behalten könnten, um die gesamte Software und Daten auf den Servern zu verschlüsseln, damit der Schlüssel kommt von unserem Server sicher in unserer Website, und vielleicht Speichervorhang von der TPM.
Wie empfehlen Sie, ein solches Problem zu lösen?
UPDATE 04/02 Ich suche nach praktischen Vorschlägen oder berate über Produkte, die mir helfen könnten, also beginne ich eine Prämie ...
Schauen Sie, Jungs, dass wir unsere Maschine im Grunde (aus geschäftlichen und praktischen Gründen) in die Kundenumgebung stellen, wir besitzen diese Maschine, und der Kunde erhält innerhalb von Stunden alles, was er bezahlt, und er kann mit den Daten tun, was er will . Aber die Algorithmen, die auf dieser Maschine laufen, und einige der dort gespeicherten Daten sind unsere Geschäftsgeheimnisse, die wir schützen wollen. Idealerweise möchte ich, dass die Maschine überhaupt nicht funktioniert, nicht einmal wenn ich nicht sage, dass es OK ist, und ohne mein OK, dass alles auf der Maschine verschlüsselt bleibt. Memory Curtaining scheint auch eine gute Möglichkeit zu sein, die Maschine während der Ausführung zu schützen.
Idealerweise würde ich auch wollen, dass die HD's und der Speicher auf allen Maschinen explodieren, sobald jemand mit einem Schraubenzieher in ihre Nähe kommt ... :-) aber ich denke, das würde es zu weit bringen ...
UPDATE 10/02 OK. Nach einigen Recherchen denke ich, dass wir etwas in die gleiche Richtung wie das PS3-Verschlüsselungssystem versuchen werden, außer dass wir die Schlüssel für die Entschlüsselung der Software und der Daten von unseren Servern einbringen werden. Auf diese Weise können wir uns für unsere Maschinen entscheiden, ob wir dem Server vertrauen, der die Schlüssel anfordert, wir können einen Kill-Schalter bekommen, indem wir einfach die Maschine neu einsetzen. Dies ist wahrscheinlich auf TPM oder etwas Ähnliches basieren, vielleicht TXT TXT ... Ich bin auch sehr daran interessiert, Memory Curtain als ein wichtiges Sicherheitsmerkmal ...
BTW, wir können das nicht lösen, indem wir die wertvollen Teile unseres Systems auf unsere Seite verlagern, sowohl wegen der Geschäftsanforderungen als auch weil es technisch nicht machbar ist - wir würden eine große Bandbreite benötigen ....
Überlegen Sie, ob Sie die Maschine vom ersten Tag an als kompromittiert behandeln können. Wenn Sie unter dieser Annahme arbeiten können, dann wird es für Sie wesentlich einfacher, aber das klingt hier nicht schrecklich lebensfähig.
Um es tatsächlich zu sichern, gibt es ein paar Bedenken:
Ich weiß, dass diese ziemlich vage sind, aber das ist wirklich die Geschichte des Spielkonsolenschutzes in den letzten paar Jahren - wenn du neugierig bist, wie das immer wieder gelöst wurde (und kaputt war), schau es dir an die Konsolenhersteller.
Es wurde nie vollständig erfolgreich durchgeführt, aber Sie können die Eintrittsbarriere signifikant erhöhen.
... Um ehrlich zu sein, hört es sich so an, als würden Sie einen Virus in Ihre Anwendung schreiben, was mich glauben lässt, dass Ihr Kunde wahrscheinlich mehr Grund hat, Ihnen nicht zu vertrauen als umgekehrt.
Das ist eine schreckliche Idee aus einer Reihe von Gründen:
Diese Frage wird 2-3 mal pro Woche auf SO gestellt, und die Antwort ist immer die gleiche - was immer Sie dem Benutzer gegeben haben, gehört Ihnen nicht mehr.
Sie können es für den Benutzer schwieriger machen, zu den Daten zu gelangen, aber Sie können nicht verhindern, dass er vollständig dorthin gelangt. Sie können die Daten verschlüsseln, Sie können den Entschlüsselungsschlüssel auf USB Cryptotoken (die den geheimen Schlüssel nicht freigibt), aber in der Theorie, wenn der Code Cryptotoken aufrufen und bitten kann, den Datenblock entschlüsseln, dann kann der Hacker duplizieren Ihr Code (in der Theorie) und diesen Code cryptotoken aufrufen, um alle Daten zu entschlüsseln.
Praktisch kann die Aufgabe kompliziert genug gemacht werden, um es unmöglich zu machen, die Daten zu erhalten. An dieser Stelle sollten Sie überprüfen, wie wichtig die entschlüsselten Daten für den Benutzer wirklich sind.
Über den Kill-Schalter : das funktioniert nicht. Noch nie. Der Benutzer kann eine Kopie erstellen und bei Bedarf aus dem Backup wiederherstellen. Er kann die Computeruhr wechseln. Er kann wahrscheinlich sogar die Uhr des Computers verlangsamen (wenn die Daten so wertvoll sind, dass eine Investition in kundenspezifische Emulationshardware möglich ist).
Über kritische Daten : Manchmal stellt sich heraus, dass Ihr wertvolles Gut für andere wirklich von geringem Wert ist [und ein anderer Aspekt Ihrer Lösung ist]. Beispiel: Wir liefern den Quellcode unserer Treiberprodukte. Es ist das wertvollste Gut für uns, aber die Benutzer zahlen nicht für Codezeilen, sondern für Support, Updates und andere Vorteile. Der Benutzer wird nicht in der Lage sein, den [gestohlenen] Quellcode effektiv zu nutzen, ohne die Summe zu investieren, vergleichbar mit den Kosten unserer Lizenz.
Über Verschleierung : Virtualisierung von Code-Stücken (z. B. VMProtect-Produkt) scheint recht effektiv zu sein, kann aber auch mit einiger Mühe umgangen werden.
Im Allgemeinen kann ich mir eine benutzerdefinierte Hardware mit einem maßgeschneiderten Betriebssystem vorstellen, die wie ein Geldautomat abgedichtet ist (so dass der Kunde nicht hineinkommt, ohne das Siegel zu brechen), regelmäßige Inspektionen usw. Das könnte funktionieren. Die Aufgabe ist also nicht nur technischer, sondern auch organisatorischer Art - Sie müssen regelmäßige Inspektionen der Maschine etc. durchführen.
Zusammenfassend : Wenn die Daten das wertvoll sind, bewahren Sie sie auf Ihren Servern auf und bieten Sie nur eine Internetverbindung an. Ansonsten können Sie die Risiken nur minimieren, nicht vollständig vermeiden.
Wie alle anderen gesagt haben, gibt es kein Wundermittel. Der Benutzer könnte die Maschine ausschalten, die HD als Slave zu einer anderen Maschine bringen, alles sichern, den Code rückgängig machen und ihn dann erfolgreich knacken. Sobald der Benutzer physischen Zugriff auf die ausführbare Datei hat, ist er potentiell kompromittiert und es gibt nichts zu tun, um ihn in 100% der Fälle zu stoppen.
Das Beste, was Sie tun können, ist, die Arbeit eines potentiellen Crackers hart zu machen, aber egal was Sie tun, es wäre nicht unzerbrechlich.
Eine Selbstzerstörung im Falle von etwas Falsches kann von einem Cracker umgangen werden, der alles sichert.
Die Verwendung eines Schlüssels in einem USB-Treiber hilft dem Cracker das Leben schwerer zu machen, kann aber letztlich von einem kompetenten, entschlossenen Cracker besiegt werden: Der Code, der Dinge entschlüsselt, kann nicht in einem verschlüsselten Zustand sein (einschließlich des Teils, der den Schlüssel bekommt) ), so ist es der große Schwachpunkt. Das Hacken dieses Teils des Codes, um den Schlüssel irgendwo anders zu speichern, macht den Schlüssel zunichte.
Wenn die Software die Authentifizierung auf einem Remote-Server vornimmt, kann dies durch Angriff auf den Client und durch Umgehung der Authentifizierung erfolgen. Wenn es einen Schlüssel vom Server erhält, kann das Sniffing des Netzwerks verwendet werden, um die Serverdaten abzufangen, die den Schlüssel enthalten. Wenn die Serverdaten verschlüsselt sind, kann der Cracker sie entschlüsseln, indem er die Software analysiert, die ihn entschlüsselt und die unverschlüsselten Daten fischt.
Im Speziellen wäre alles viel einfacher für einen Cracker, wenn er einen Emulator verwendet, um Ihre Software auszuführen, die Snapshots des Speichers speichern kann (einschließlich einer unverschlüsselten Version des Algorithmus). Noch einfacher, wenn er den Speicher direkt manipulieren und fixieren kann, während er die Software ausführt.
Wenn Sie nicht erwarten, dass Ihr nicht vertrauenswürdiger Kunde sehr entschlossen ist, können Sie die Dinge nur erschweren und hoffen, dass sie nie genug Energie und Fähigkeiten bekommen, um sie zu brechen.
Die bessere Lösung ist meines Erachtens, dass Sie die gesamte Software auf Ihrem vertrauenswürdigen Server installieren und den Server dazu bringen, Ihren Server dazu zu bringen, die Aufgabe zu erledigen und Ihre Algorithmen auf Ihrem Server zu belassen. Dies ist viel sicherer und einfacher als alles andere, weil es das grundlegende Problem beseitigt: Der Benutzer hat keinen physikalischen Zugriff mehr auf den Algorithmus. Sie sollten wirklich, wirklich über eine Weise nachdenken, indem Sie Ihre Bedürfnisse beseitigen, um den Code im Klienten zu behalten. Auch wenn dies nicht unumkehrbar ist, kann ein Hacker ableiten, was der Algorithmus macht, indem er analysiert, was die Ausgabe in Abhängigkeit von der Eingabe ist. In den meisten Szenarien (das sieht nicht so aus) ist der Algorithmus nicht der wichtigste im System, sondern die Daten sind.
Wenn Sie es also nicht vermeiden können, den Algorithmus in der nicht vertrauenswürdigen Gruppe auszuführen, können Sie nicht viel mehr tun als das, was Sie bereits gesagt haben: alles verschlüsseln (vorzugsweise in Hardware), authentifizieren und alles überprüfen, zerstören Daten, bevor jemand darüber nachdenkt, es zu sichern, wenn Sie vermuten, dass etwas nicht stimmt, und es so schwer wie möglich machen, dass jemand es knackt.
ABER WENN SIE WIRKLICH WÜNSCHE IDEEN WÜNSCHEN UND WIRKLICH DAS TUN MÖCHTEN, HIER GEHEN WIR:
Ich könnte vorschlagen, dass Sie Ihre Programmmutante machen. I.E: Wenn Sie Ihren Code entschlüsseln, verschlüsseln Sie ihn mit einem anderen Schlüssel und werfen Sie den alten Schlüssel weg. Holen Sie einen neuen Schlüssel vom Server und bestätigen Sie, dass der Schlüssel selbst so codiert ist, dass es sehr schwierig wäre, den Server mit etwas zu verhöhnen, das kompromittierte neue Schlüssel liefert. Stellen Sie sicher, dass der Schlüssel eindeutig ist und nicht wiederverwendet wird. Auch dies ist nicht unzerbrechlich (und das erste, was ein Cracker tun würde, ist genau dieses Feature anzugreifen).
Eine weitere Sache: Legen Sie eine Menge nicht-offensichtliche rote Heringe, die nicht-seltsame Konsistenzprüfungen, die eine Menge nicht funktionsfähige gefälschte Version Ihres Algorithmus und fügt eine Menge komplexer Überblutung, die effektiv nichts tut und behauptet dass es wie erwartet von echtem Code ausgeführt wird. Machen Sie den echten Code, um Dinge zu tun, die seltsam und nicht-sinnlich aussehen. Das macht das Debuggen und Reverse-Engineering noch schwieriger, da der Cracker viel Mühe darauf verwenden muss, das Nützliche von dem, was Junk ist, zu trennen.
EDIT: Und natürlich, machen Sie einen Teil des Junk-Codes besser als der richtige aussehen, so würde ein Cracker zuerst dort aussehen, effektiv Zeit und Geduld verlieren. Unnötig zu sagen, alles zu verschleiern, also selbst wenn der Cracker den unverschlüsselten Code bekommt, sieht er immer noch verwirrend und sehr seltsam aus.
Ich weiß, dass andere wahrscheinlich Löcher in diese Lösung stecken werden - und ich fühle mich frei, dies zu tun, wenn ich so etwas lebe, und ich würde die Herausforderung begrüßen! - Aber warum nicht:
Da Sie eindeutig Windows verwenden, aktivieren Sie den Bit-Locker-Laufwerkschutz auf der Festplatte mit den maximalen Sicherheitseinstellungen. Dies wird dazu beitragen, Menschen zu entschärfen, die das Laufwerk klonen, als mein Verständnis - Wenn ich falsch liege, sag es! - Ist sein Inhalt basierend auf diesen Systemhardwareeinstellungen verschlüsselt.
Aktivieren Sie TPM auf der Hardware und konfigurieren Sie es für Ihre Software richtig. Dies wird helfen, Hardware Sniffing zu stoppen.
Deaktivieren Sie alle nicht von Ihnen verwendeten Konten, und sperren Sie die Systemkonten und -gruppen, um nur das zu verwenden, was Sie benötigen. Bonuspunkte für die Einrichtung von Active Directory und ein gesichertes VPN, damit Sie über eine Hintertür auf das Netzwerk zugreifen können, um das System ohne einen offiziellen Besuch vor Ort zu überprüfen.
Um den technischen Aufwand zu erhöhen, müssen Sie die Software in C ++ oder einer anderen non-net-Sprache schreiben, da MSIL byte-code leicht von öffentlich verfügbaren kostenlosen Tools in den Quellcode de-kompilierbar ist braucht mehr technische Fähigkeiten, um etwas in der Montage zu dekompilieren, auch wenn es mit den richtigen Werkzeugen noch sehr gut machbar ist. Stellen Sie sicher, dass Sie alle CPU-Anweisungen für die Hardware, die Sie verwenden, aktivieren, um die Angelegenheit noch komplizierter zu machen.
Lassen Sie Ihre Software das Hardwareprofil (eindeutige Hardware-IDs) des bereitgestellten Systems regelmäßig überprüfen. Wenn dies fehlschlägt (wie in der Hardware geändert wurde), muss es sich selbst zerstören.
Sobald die Hardware validiert wurde, laden Sie Ihre Software von einem verschlüsselten Binär-Image, das in eine verschlüsselte RAM-Disk geladen wurde, die dann selbst im (nicht gepinnten!) Speicher entschlüsselt wird. Stecken Sie es nicht fest, oder verwenden Sie eine konstante Speicheradresse, da dies eine schlechte Idee ist.
Seien Sie sehr vorsichtig, wenn die Entschlüsselung abgeschlossen ist, werden die Schlüssel aus dem RAM entfernt, da einige Compiler dummerweise einen nicht gesicherten bzero / memset0 Aufruf optimieren und Ihren Schlüssel im Speicher belassen.
Denken Sie daran, dass Sicherheitsschlüssel im Speicher durch ihre Zufälligkeit in Bezug auf andere Speicherblöcke erkannt werden können. Um dies zu verringern, stellen Sie sicher, dass Sie mehrere "Dummy" -Schlüssel verwenden, die, falls sie verwendet werden, ein Intrusion Detection- und Explode-Szenario auslösen. Da Sie den von den Schlüsseln verwendeten Speicher nicht fixieren sollten, können die Benutzer die gleichen Dummy-Schlüssel mehrmals auslösen. Bonuspunkte, wenn alle Dummy-Schlüssel nach dem Zufallsprinzip erzeugt werden können und der echte Schlüssel jedes Mal aufgrund der unten stehenden Nummer 12 unterschiedlich ist, so dass sie nicht einfach nach dem Schlüssel suchen können, der sich nicht ändert .. weil sie alle tun.
Verwenden Sie polymorphen Assemblercode. Denken Sie daran, dass Assembly in Wirklichkeit nur Zahlen ist, die basierend auf den Anweisungen und dem Status des Stacks / was zuvor aufgerufen wurde, selbst modifiziert werden kann. Zum Beispiel kann in einem einfachen i386-System 0x0F97 (Set-Byte, wenn oben) leicht das genaue Gegenteil (Set byte wenn) Anweisung durch einfaches Subtrahieren von 5 sein. Verwenden Sie Ihre Schlüssel, um den Stack zu initialisieren und den L1 / L2-Cache der CPU zu nutzen möchte einen harten Kern haben.
Stellen Sie sicher, dass Ihr System das aktuelle Datum / die aktuelle Uhrzeit versteht und dass das aktuelle Datum / die aktuelle Uhrzeit in akzeptablen Bereichen liegt. Der Start am Tag vor der Bereitstellung und die Begrenzung auf 4 Jahre wären mit der Glockenkurve des Hardwarefehlers für Festplatten unter Garantie / Support vereinbar, sodass Sie einen solchen Schutz nutzen und zwischen den Hardwareupdates eine gute Zeit haben. Wenn diese Validierung fehlschlägt, muss sie sich selbst beenden.
Sie können helfen, Leute, die sich mit der Uhr herumschlagen, zu entschärfen, indem Sie sicherstellen, dass Ihre pid-Datei mit der aktuellen Zeit immer wieder aktualisiert wird. Der Vergleich der letzten modifizierten Zeit (als verschlüsselte Daten und deren Dateiattribute im Dateisystem) mit der aktuellen Zeit wird ein Frühwarnsystem für Personen sein, die mit der Uhr geschraubt haben. Wenn ein Problem erkannt wurde, explodieren.
Alle Datendateien sollten mit einem Schlüssel verschlüsselt werden, der sich auf Ihrem Befehl aktualisiert. Stellen Sie Ihr System so ein, dass es mindestens einmal pro Woche und bei jedem Neustart aktualisiert wird. Fügen Sie dies der Funktion "Update-from-your-Servers" Ihrer Software hinzu, die Sie haben sollten.
Die gesamte Kryptografie sollte den FIPS-Richtlinien entsprechen. Verwenden Sie daher eine starke Verschlüsselung, verwenden Sie HMACS usw. Sie sollten versuchen, die FIPS-140-2-Level-4-Spezifikationen in Anbetracht Ihrer aktuellen Situation zu treffen, aber einige der Anforderungen sind aus ökonomischer Sicht und realistisch FIPS-140 verständlicherweise nicht durchführbar -2-level-2 kann deine Grenze sein.
Lassen Sie es in allen Selbstzerstörungsfällen zuerst zu Ihnen anrufen, damit Sie sofort wissen, was passiert ist.
Und schließlich einige Nicht-Software-Lösungen:
Wenn es nicht nach Hause telefonieren kann ..Als letzter Versuch wird ein benutzerdefiniertes Hardware-Gerät an einen internen seriellen / USB-Port angeschlossen, der ein Relais aktivieren soll, das dann einen Block von Thermit auslöst, wenn es einen Fall, eine Hardware oder Software-Manipulation erkennt. Wenn Sie es auf die Festplatten legen und diese über das Motherboard legen, wird es am besten funktionieren. Sie müssen jedoch mit Ihrer Rechtsabteilung nach den erforderlichen Genehmigungen fragen, wenn dies keine vom US-Militär genehmigte Situation ist, da ich davon ausgehe, dass Sie sich in den USA befinden.
So stellen Sie sicher, dass die Hardware nicht manipuliert wird. Weitere Informationen zur physischen Sicherheit des Systems finden Sie unter Physische Sicherheitsanforderungen für FIPS. Bonuspunkte, wenn Sie die modernen Racks, die Sie verwenden, in einem alten AS400-Gehäuse als Tarnung verschrauben / verschweißen, um die Bewegung / Manipulation der Hardware zu verringern. Jüngere Jungs werden nicht wissen, was zu tun ist und sich Sorgen machen, "alte Sachen zu blasen", ältere Leute werden sich fragen "wtf?", Und die meisten werden Blut hinter sich lassen, das später als Beweis für Manipulationen benutzt werden kann, wenn sie an den oft manipulieren scharfkantigen Fall, zumindest basierend auf meiner eigenen Erfahrung.
Im Falle einer Intrusion Notification, nuke es aus dem Orbit .. es ist der einzige Weg, um sicher zu sein. Stellen Sie sicher, dass Sie alle rechtlichen Formulare und Anforderungen für den Zugang ausgefüllt haben, so legal ist mit der Minderung des Risikos oder der Haftung zufrieden ... Oder Sie können Ihr Benachrichtigungssystem auf E-Mail / Text / Telefon automatisch einrichten, sobald Sie ein Benachrichtigung, dass Sie explodierte.
"Die einzige Möglichkeit, ein vollkommen sicheres System zu haben, besteht darin, es mit einem Hammer zu zerschlagen"
Das heißt, es ist möglich, mit den Möchtegern-Hackern genug zu tun, um mehr Ärger zu machen, als es wert ist. Wenn es sich bei der Maschine um eine "Black Box" handelt, in der sie nicht wirklich direkt darauf zugreifen können, sondern Programme, die damit umgehen, dann ist Ihr physischer Zugang die größte Bedrohung. Sie können Fälle sperren und sogar ein kleines, zerbrechliches Element in das Gehäuse einfügen, das beim Öffnen des Falls aufgeschnappt wird ... stellen Sie sicher, dass Ihre Servicemitarbeiter dieses Element immer ersetzen ... es wird Sie wissen lassen, ob jemand geöffnet hat es ohne Genehmigung (ja, es ist ein alter Teenager Trick, aber es funktioniert). Deaktivieren Sie physisch alle Hardware-Teile (wie USB-Ports), die Sie nicht unbedingt benötigen.
Wenn Sie es mit einer Maschine zu tun haben, die keine Black-Box ist, verschlüsseln Sie alles aus ... 256-Bit-Verschlüsselung ist praktisch unmöglich ohne den Schlüssel zu knacken ... dann wird der Trick zum Schlüssel.
Theoretisch könnten Sie möglicherweise den Schlüssel ändern (durch erneutes Verschlüsseln der Daten) und nur durch einen Prozess abrufbar sein, der direkt mit Ihren (sicheren) Servern kommuniziert.
Zusätzlich verfolgen Sie alles, was mit der Box passiert, insbesondere alles, was in der Software passiert, die außerhalb der normalen Nutzung ist. Vieles davon kann dich nicht vor jemandem schützen, der wirklich, wirklich entschlossen ist ... aber es kann dich warnen, dass dein System kompromittiert wurde. (auf dem du den Teufel verklagen kannst, wer auch immer eingebrochen ist)
Was den Kill-Switch angeht ... nun, Schlaf-Viren sind da draußen, aber wie schon gesagt, können sie sich täuschen lassen oder durch Zufall aufgestört werden. Ich würde vorschlagen, dass, anstatt sich sauber zu wischen, wenn Sie eine Verletzung vermuten, das System alles mit einem zufällig generierten Schlüssel verschlüsseln lassen, den Schlüssel zu Ihren Servern schicken (damit Sie den Schaden rückgängig machen können), und dann 'shredden' Datei, die den Schlüssel enthielt. (Viele Dateivernichter da draußen können Daten so gut zerstören, dass es (fast) unmöglich ist, sie wiederherzustellen.)
Zusammenfassung der Antworten, ja. Es gibt keine "vollkommen sicheren" Lösungen für dieses Problem, da es eine homomorphe Verschlüsselung (die jetzt nur in der Form existiert) benötigen würde von begrenzten Prototypen, die lächerliche Mengen an Berechnung erfordern).
Was Sie in der Praxis brauchen, ist die Kombination von richtigem Requirements Engineering und Sicherheitstechnik (Bewerten Sie Stakeholder, Interessen, wertvolle Vermögenswerte innerhalb des implementierten Systems, mögliche Angriffe und Schäden durch jedes erfolgreiche Angriffsszenario VS Kosten, um davor zu schützen.)
Danach werden Sie entweder sehen, dass der Schutz nicht wirklich benötigt wird, ODER Sie können einige vernünftige Maßnahmen ergreifen und andere "Löcher" mit legalem Zeug abdecken ODER das System komplett neugestalten, beginnend mit dem Geschäftsmodell ( Unwahrscheinlich, aber auch möglich).
Im Allgemeinen ist Sicherheit das Problem des Systems Engineering, und Sie sollten sich nicht nur auf technische Ansätze beschränken.
Tags und Links .net security encryption obfuscation tpm