Sicherer File Tresor

HerrInfo

Aktives Mitglied
Hallo zusammen, ich habe mir überlegt, als Projekt ein Programm zu erstellen, mit welchem ich Files sicher lokal speichern kann, ohne dass jemand an sie herankommt. Die jetzige Idee ist es, die Files mit AES-256-Bit zu verschlüsseln und dann in einem Folder pro User abzulegen. Die User können sich dann ein Passwort ausdenken und bekommen noch ein Salt generiert. Kommen wir jetzt zur eigentlichen Frage: Ist diese Methode sicher? Und kann man irgendwie die Daten lokal speichern, ohne dass sie im Windows-Explorer zu finden sind? Und wie würde ich das Login Fenster machen, wo User sich ganz normal in das Programm einloggen können mit einem weiteren password (wird nicht zur Verschlüsselung benutz), weil ich dieses ja speichern muss, um es abzugleichen.
 
Kommen wir jetzt zur eigentlichen Frage: Ist diese Methode sicher?
Grundsaetzlich Ja, aber...viele, viele Fragen und Fallstricke.

Und kann man irgendwie die Daten lokal speichern, ohne dass sie im Windows-Explorer zu finden sind?
Du kannst sie alle in einer einzigen Datei ablegen. Dann sieht man nur die "Tresor-Datei" wenn man das Dateisystem betrachtet.

Und wie würde ich das Login Fenster machen, wo User sich ganz normal in das Programm einloggen können mit einem weiteren password (wird nicht zur Verschlüsselung benutz), weil ich dieses ja speichern muss, um es abzugleichen.
Idealerweise speicherst du das Passwort nicht, sondern laesst das jedes mal vom Benutzer eingeben. Tatsaechlich musst du das Verschluesselungspasswort gar nicht speichern, es reicht vollkommen wenn du deine "Tresor-Datei" mit einer Markierung versiehst, dann versuchst diese zu entschluesseln und dann pruefst. Also, quasi sowas (Pseudo-Code):

Java:
String password = getPasswordFromUser();
Path safePath = getSafePathOfThatUser();

byte[] first128Bytes = readFirst128BytesFrom(safePath);
byte[] decryptedHeader = decrypt(first128Bytes, password);

if (decryptedHeader.matches("SuperSpecialHeaderToDetermineWhetherDecryptionWorked")) {
    // TODO Correct password.
} else {
    // TODO Wrong Password.
}

---

Das gesagt, wenn du das nicht als Uebung in Kryptographie und Sicherheitsverwaltung entwickeln willst, waere vermutlich eine bereits existierende Loesung besser.

Wie @Dukel bereits sagte, VeraCrypt waere eine Moeglichkeit, gocryptfs eine weitere welche auf Basis von Dateien funktioniert, so auch PicoCrypt. Es gibt noch File Lock PEA welches ein Java Programm ist unter der GPL.
 
Vielen Dank für die schnellen Antworten.

Es soll eher eine Übung sein, welche am Ende auch relativ sicher ist. Wenn ich das Ganze in eine Datei speicher, wie kann ich denn dann, wenn User A 2 PDFs speichert und User B 3 Fotos, unterscheiden zwischen den Datei-Arten und welchem User diese gehören?
 
Vielen Dank für die schnellen Antworten.

Es soll eher eine Übung sein, welche am Ende auch relativ sicher ist. Wenn ich das Ganze in eine Datei speicher, wie kann ich denn dann, wenn User A 2 PDFs speichert und User B 3 Fotos, unterscheiden zwischen den Datei-Arten und welchem User diese gehören?
Unterschiedliche Dateien pro Benutzer. Jeder Benutzer bekommt eine eigene "Tresor-Datei" welche man beim Starten auswaehlen muss (oder automatisch gewaehlt wird). Hat den Vorteil dass ein Benutzer auch mehrere mit unterschiedlichen Passwoertern haben kann. So funktioniert zum Beispiel auch KeepassXC.
 
Es soll eher eine Übung sein
Was genau willst du üben?

Generell ist vieles denkbar bis hin zur Erstellung eines eigenen Filesystems. Aber je nachdem, was du lernen willst, macht das keinen Sinn.

Und auch beim Thema Verschlüsselung: da gibt es bereits sehr viel und je nachdem, was du lernen willst, greifst du dann auf Libaries oder Klassen des Frameworks zu.

Es gibt z.B. den Cryptomator als App und auch als Library …. Das könnte interessant sein, wenn du den Bereich Kryptographie nicht tief einsteigen möchtest.

Und wenn du in das Themengebiet einsteigen möchtest, dann ist vermutlich etwas mehr Theorie sinnvoll. Da steigt man nicht ein und programmiert einfach etwas …

Das wäre so wäre so meine Sicht und Rückfrage.
 
Es soll eher eine Übung sein, welche am Ende auch relativ sicher ist.
Zur Übung...ok. Ernsthaft einsetzen würde ich das an deiner Stelle aber auf gar keinen Fall, nimm da lieber etwas daß bereits fertig und weit verbreitet (=ausgiebig getestet) ist.

Du wärst nicht der Erste, der ein Programm um einen eigentlich hinreichend sicheren Kryptoalgorythmus herum baut, aber aufgrund ungeschickter Implemementierung irgendein großes Loch in den Zaun reißt. Es ist leicht, irgendetwas vor sich selbst zu sichern. Es vor anderen zu sichern ist deutlich schwerer.
 
Was genau willst du üben?
Als eigentlichen Fokus wollte ich mich mit der Implementierung von AES256bit beschäftigen und damit die files verschlüsseln und währenddessen auch etwas in hash einsteigen.
Generell ist vieles denkbar bis hin zur Erstellung eines eigenen Filesystems.
Ein eigenes Filesystem wäre auch denkbar, habe mich damit aber noch garnicht beschäftig.

Verschlüsseln mache ich im Moment wie folgt:
Java:
package net.tim;

import javax.crypto.*;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.spec.SecretKeySpec;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.security.InvalidAlgorithmParameterException;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.security.spec.InvalidKeySpecException;
import java.security.spec.KeySpec;
import java.util.Base64;

public class EncryptionService {
    private static final String ALGORITHM = "AES/CBC/PKCS5Padding";

    public static void CipherFile(boolean encrypt,IvParameterSpec iv , SecretKey key,
                                  File inputFile, File outputFile)
            throws IOException, NoSuchPaddingException, NoSuchAlgorithmException,
            InvalidAlgorithmParameterException, InvalidKeyException, BadPaddingException,
            IllegalBlockSizeException {

        Cipher cipher = Cipher.getInstance(ALGORITHM);

        if (encrypt) {
            cipher.init(Cipher.ENCRYPT_MODE, key, iv);
        } else {
            cipher.init(Cipher.DECRYPT_MODE, key, iv);
        }
        FileInputStream inputStream = new FileInputStream(inputFile);
        FileOutputStream outputStream = new FileOutputStream(outputFile);
        byte[] buffer = new byte[64];
        int bytesRead;
        while ((bytesRead = inputStream.read(buffer)) != -1) {
            byte[] output = cipher.update(buffer, 0, bytesRead);
            if (output != null) {
                outputStream.write(output);
            }
        }
        byte[] outputBytes = cipher.doFinal();
        if (outputBytes != null) {
            outputStream.write(outputBytes);
        }
        inputStream.close();
        outputStream.close();
    }

    public static void CipherFile(boolean encrypt, File inputFile, File outputFile, User user, String password) {
        try {
            SecretKey key = getKeyFromPassword(password, new String(user.getSalt()));
            IvParameterSpec iv = new IvParameterSpec(user.getIv());
            CipherFile(encrypt, iv, key, inputFile, outputFile);
        } catch (IOException | NoSuchAlgorithmException | NoSuchPaddingException | InvalidAlgorithmParameterException | InvalidKeyException | BadPaddingException | IllegalBlockSizeException | InvalidKeySpecException e) {
            e.printStackTrace();
        }
    }

    public static IvParameterSpec generateIv() {
        SecureRandom randomSecureRandom = new SecureRandom();
        byte[] iv = new byte[16];
        randomSecureRandom.nextBytes(iv);
        return new IvParameterSpec(iv);
    }

    public static SecretKey getKeyFromPassword(String password, String salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
        SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
        KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(), 65536, 256);
        return new SecretKeySpec(factory.generateSecret(spec).getEncoded(), "AES");
    }

    //Method to generate a random salt
    public static String getSalt() {
        SecureRandom random = new SecureRandom();
        byte[] salt = new byte[16];
        random.nextBytes(salt);
        return new String(salt);
    }

    //Generate a Hash from a password
    public static String getHash(String password, String salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
        SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
        KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(), 65536, 256);
        byte[] hash = factory.generateSecret(spec).getEncoded();
        return Base64.getEncoder().encodeToString(hash);
    }
}

Wie könnte ich denn ein fertiges Programm testen, ich habe ein paar Ideen für Schwachstellen aber wie genau kann ich diese testen? JUnit Tests prüfen ja nur die Funktionen und diese Funktionieren einwandfrei.
 
Ich glaube, die Verschlüsselung ist sicher, da AES als im Moment nicht mit Bute-Force lösbar gilt. Deshalb könnte ich mir vorstellen, dass ein Problem das Login field seien kann, wo man das Password eingibt (anfällig gegenüber Keyloggern) eine weite Schwachstelle könnte code Injektion sein, wüsste aber nicht, wie man sich dagegen absichert. Projekt: https://github.com/Ghoastplayer/SecureFileVault
 
Deshalb könnte ich mir vorstellen, dass ein Problem das Login field seien kann, wo man das Password eingibt (anfällig gegenüber Keyloggern) eine weite Schwachstelle könnte code Injektion sein, wüsste aber nicht, wie man sich dagegen absichert.
Gar nicht, entweder du vertraust der Client-Umgebung, oder nicht. Weil egal was du einbaust, der Client kann immer noch darueber hinweg. Wenn du die Client-Umgebung "validieren" willst, bist du unmittelbar im selben Bereich wie "Client Anti-Cheat" Loesungen, und Googles Play Integrity. Also kurzum, entweder du installierst ein Root-Kit auf dem System und vertraust dass die Hardware nicht zerbrochen ist, oder du vertraust nur der Hardware, aber dann musst du eben auch die Hardware stellen (und 100% ist das theoretisch auch wieder nicht), oder du vertraust dem System einfach, weil dagegen verteidigen kannst du dich ohnehin nicht.
 

Zurück
Oben