Arbeitsspeicher verschlüsseln

[Guest]

Gibt es eine Möglichkeit den Arbeitsspeicher zu verschlüsseln, um ein auslesen durch Dritte zu verhindern?

 

[Gast]

kurze antwort: nein.
schwammige antwort: nutzdaten schon
sinnvolle antwort: denk dir was anderes aus, um dein programm zu schützen

 

[Kim Stebel]

dritte? also andere programme? wird durch das betriebssystem eh schon verhindert

 

[Guest]

aber sicher ohne großen Aufwand umgehbar nehm ich an

 

[Kim Stebel]

nimmst du falsch an. lies ein buch über betriebssysteme, schlag das kapitel über memory management auf....

 

[AlArenal]

Hat das eigentlich IRGENDWAS mit Java zu tun?

 

[Kim Stebel]

man ist ja schon froh, wenn es keine frage zu javascript ist

 

[AlArenal]

Du meinst man sollte die Erwartungen an das Niveau anpassen?

 

[ice-breaker]

Da gibts doch diese eine ganz bekannte software, ice-irgendwas oder so, die umgeht ja (wie auch immer) den Schutz von Windows und du kannst dir die Ram-Bereiche anzeigen lassen.
Hätte zwar nie gedacht, dass es sowas gibt, aber auch ich wurde eines besseren belehrt.

Edit: SoftICE

 

[Kim Stebel]

Die Software umgeht den Schutz nicht, die wird vor Windows geladen. Dazu musst du sie aber erst mal installieren können und den Rechner neu starten. Mit anderen Worten: Es ist _dein_ Rechner oder du hast Admin-Privilegien. Und dann kann man natürlich gar nichts vor dir verstecken. *Kopfschüttel*

 

[Leroy42]

Du meinst man sollte die Erwartungen an das Niveau anpassen?

Genau! Auf Neudeutsch nennt man das ypsilantisieren!

 

[Guest]

Mit JAVA hat das insofern zu tun, dass ich die VM verschlüsseln will.

 

[Kim Stebel]

die VM verschlüsseln...jetzt wird's aber abenteuerlich

 

[AlArenal]

Danach will er vermutlich den Schlüssel wegwerfen, aus Sicherheitsgründen.

 

[tuxedo]

Am besten noch den ganzen Rechner in einen Safe einbetonieren. Man könnte sich ja auf diverse Daten- und Adressleitungen geklemmt haben ...

- Alex

 

[thE_29]

Ich weiß nicht warum das von euch jetzt so ins lächerliche gezogen wird.

1. kann man den RAM auslesen (siehe SoftIce oder zB ein bißchen älterer Anlass der Key für AACS bei HD DVD/Blu-ray konnte aus dem RAM ausgelesen werden beim Corel WinDVD oder so einer Software).
2. Hat es auch mal einen Ansatz gegeben von verschlüsselten Jars (da hat sich was zwischen die JVM gehängt, was die Jars dann entschlüsselt hat - ich hab das mal verfolgt, aber irgendwie gibts die Firma nicht mehr)
3. Im heutigen Zeitalter von Bundestrojaner und co. was ist da so schlimm etwas über eine Zusätzliche Verschlüsselung rauszufinden? (zZ machen ja viele HDD Verschlüsselungen)

 

[tuxedo]

Wenn es um so brisante Daten geht, dass man anfängt den Arbeitsspeicher zu verschlüsseln, dann sollte man sich doch fragen ob Java die richtige Sprache dafür ist (Stichwort dekompilierbarkeit. Da gibts andere Sprachen wo einem größere Steine im Weg liegen).

Zudem sollte man sich fragen, ob der betreffende Anwenderkreis zu den "extremen" gehört die sich die Arbeit machen den RAM zu untersuchen. Wie ja schon geschrieben wurde, ist es selbst mit SoftICE ein recht großer Aufwand und nicht nur mit 3 Klicks zu bewerkstelligen.

Der einfachste Ansatz wäre wohl der, sämtliche Werte von Variablen und Co. von vornherein nur "verschlüsselt/verstümmelt" vorzuhalten (wurde glaub ich schon erwähnt). Finde deshalb den Titel dieses Threads auch etwas "ungenau". "Arbeitsspeicher verschlüsseln" klingt so nach "ich halte meine Variablen lesbar und verschlüssle hinterher einfach den gesamten von mir benutzten RAM."

Es wurde ja auch schon oft genug die Sache mit dem "verschlüsseln" des resultierenden ByteCodes diskutiert. Fazit war mehr oder weniger immer: Völlig sicher wirds nie. Und der Aufwand bis es "ziemlich" sicher ist, ist so hoch, dass es sich bzgl. Kosten/Nutzungsrechung nur sehr selten lohnt mehr als einen Obfuscator und vorrausschauende Programmierung anzuwenden.

Vermutlich deshalb der Hang zum "lächerlichen".

 

[AlArenal]

Die Leute sollten ihre Zeit lieber damit verbringen bessere Software im Sinne von Funktionalität und Benutzerfreundlichkeit zu schreiben, anstatt in bester Schäuble-Manier ne Paranoia zu schieben und so zu tun, als sei ihr Hello-World so unglaublich wertvoll, dass es unter keinen Umständen in Feindeshand gelangen dürfe - so denn überhaupt einer daran Interesse hätte.

Am besten behält man die Software für sich, auf einem Rechner der nicht vernetzt ist (damit keiner rein kann), keine Datenträger hat (damit keiner was klauen kann) und der nie eingeschaltet ist (damit nichts abgehört werden kann). Dann erzählt man auch am besten niemanden davon (damit keiner neidisch werden kann) und freut sich im stillen Kämmerlein ein zweites Poloch, weil man doch so ein genialer Coder ist...

I would never tell a lie. I promise!

 

[thE_29]

Naja, es gibt auch Bankensoftware die mit Java läuft.

Von daher denke ich mir schon, dass es auch dort etwas sicherer noch geht.

Aber wie du auch schon gesagt hast, ist ein großes Problem die Dekompilierbarkeit von Java. Das hat aber mit den verschlüsselten Jars nicht mehr funktioniert.
Warum die Firma das nicht besser vermarktet hat, ist mir zwar unklar, aber vielleicht tut sich in dem Bereich noch was. (Da die JVM ja offen ist, oder?)


@Al: Natürlich kommt es auch drauf an, was für ne SW man schreibt! Wenns nur HelloWorld Programme sind, isses egal! Wenns was sicherheitsrelevantes wäre, ist das sicher ein Thema!

 

[Wildcard]

Warum muss Bankensoftware unkompilierbar/"verschlüsselt" sein?
Die Schlüssel sollen sicher sein, die Daten sollen sicher sein, die Kommunikation soll sicher sein. Warum der Quellcode?

 

[AlArenal]

Damit keiner sehen kann wie gruselig der Code ist

Security by Obscurity

 

[Guest]

Am besten noch den ganzen Rechner in einen Safe einbetonieren. Man könnte sich ja auf diverse Daten- und Adressleitungen geklemmt haben ...

- Alex

der beste schutz vor übergriffen sind immer noch zwei meter stahlbeton und nen wachmann mit mp

 

[thE_29]

@Wildcard: Weil ich dann fix mitdebuggen kann und mir einfach Variableninhalte so angucken kann (braucht man nicht blöd im Speicher suchen). Oder einfach irgendwelche Objektmethoden aufrufen kann (zB getKey und vola hab ich den Key).

 

[ms]

Da ich gerade in einer Bank sitze.
Nein, es wird hier kein Code verschlüsselt, es gibt hier wie in den meisten Fällen eine eigene Abteilung die sich nur um den Betrieb der Applikation kümmert. Dazu gehören auch sicherheitsrelevante Themen.
Das Verschlüsseln von Code zur Laufzeit ist ja auch Schwachsinn, da der Code im Falle einer Bank ja nicht außer Haus gelangt.
Im CVS/SVN kann jeder berechtigte Entwickler den Code auschecken und einsehen. So gesehen sind die Entwickler und auch die Admins das echte Sicherheitsrisiko.

Sicherheit kostet aber ab einem gewissen Grad viel mehr Geld als ein paar gute Anwälte. Darum reichen bis zu diesem Grad die üblichen Standardsicherheitsmaßnahmen (gesicherte Übertragung, Firewalls, Berechtigungen, ...) und darüber hinaus Geheimhaltungserklärungen plus Unterschriften der Beteiligten.

Ob der Code des TO es wirklich Wert ist kann ich nicht beurteilen. Eine Möglichkeit wäre die relevanten Codeteile als Service anzubieten. (SaaS).

ms

 

[tfa]

@Wildcard: Weil ich dann fix mitdebuggen kann und mir einfach Variableninhalte so angucken kann (braucht man nicht blöd im Speicher suchen). Oder einfach irgendwelche Objektmethoden aufrufen kann (zB getKey und vola hab ich den Key).

Welchen Key denn? Deinen eigenen? Einen anderen wirst du wohl kaum auf deinem Client finden (dürfen). Geheime Daten, Berechnungen etc. gehören auf den Server, nicht auf den Client. Alles andere ist prinzipiell unsicher, egal ob dekompilierbares Java oder Maschinensprache.
Security by Obscurity ist eine schlechte Strategie. Manche Leute behaupten, so richtig sicher können nur Open Source Programme sein. Nur die kann man auf Lücken, Hintertürchen usw. überprüfen.

 

[alexDgGG]

Vielleicht doch etwas sicherer?

Also den Code zu schützen hat schon nen Sinn. Die sichersten Verschlüsselungsmethoden die momentan existieren beruhen auf fraktalen oder akausalen Algorithmen (wie übrigens gerne von Terroristen verwendet). Bei diesen Methoden reicht der Schlüssel alleine nicht aus, man braucht auch noch einen gegenschlüssen (bmp-Verschlüsselung). In diesem fall ist der Algorithmus selber der Gegenschlüssel und muss vor Zugriff/Einsicht geschützt werden. Also doch hochbrisant… und da muss sich noch was tun in Java, weil so wie im Moment ist es sch…e.