@nitrokey
Ist es möglich am neuen Nitrokey 3 das Zurücksetzen mit einem Master-PIN zu schützen?

Und kann ich ssh-Zertifikate (sic! Nicht die Pubkeys!!!) auch am Stick speichern?

@nitrokey Ich hab euch eh schon einmal gefragt und das Szenario geschildert, warum ein Zurücksetzen mit Master-PIN (so wie es etoken macht) sinnvoll und für den Einsatz bei uns im Unternehmen unumgänglich ist.

Angenommen:
Ein kompromittierter Rechner ist im Unternehmen. Der Mitarbeiter steckt seinen Key rein, und der komprommitierte Rechner setzt beim Einstecken des Sticks diesen zurück, da es ohne Master-Key geht. Der Stick ist raus. Der MA kommt nicht mehr auf seine Server.

Es kommt der Admin, und steckt seinen Key in den rechner (es ist noch nicht bekannt, dass der Rechner kompromittiert ist). Und auch sein Stick wird zurückgesetzt.
Es kommt der 3 Admin... und schon sind im schlimmsten Fall alle wesentlichen Tokens unbrauchbar und die Admins auch von den Servern ausgesperrt.

Ein Szenario, welches mit Rücksetzen ausschließlich mit Master-Key nicht möglich ist, das so aber ein ungutes DoS verursachen kann.

Und mit SSH-Zertifikaten meine ich das:

https://ef.gy/hardening-ssh

Ein wirklich geniales, relativ neues Feature von openssh (hat auch schon ein paar Jahre auf dem Buckel... aber im Vergleich zu ssh selbst, ist es relativ neu)

@nitrokey Ich meine nicht die Private-Keys. Ich meine ZERTIFIKATE! Das ist etwas anderes.

Ich kann einen Pubkey oder auch einen Hostkey mit einer CA Zertifizieren (diese wird AUCH mit ssh-keygen erzeugt!!!).
auf dem Host wird dann nur mehr das CA-Zertifikat hinterlegt (keine Pubkeys in einer authorized-keys Datei mehr!!!) , mit der die User-Pubkeys zertifiziert wurden und am Client wird nur mehr ein CA-Zertifikat hinterlegt, von der die Host-Keys der Server signiert wurden.
Es gibt dann auch keine Datei "known-hosts" mehr. ssh prüft ob der Key, der sich einloggen möchte auch von der hinterlegten CA zertifiziert wurde (bzw. der Client prüft, ob der Hostkey mit der richtigen CA zertifiziert wurde).

Das ist eine Erweiterung zum klassischen Priv/Pubkey-Authentifizierungs-Modell von openssh.

Im Zertifikat können noch IP-Adressen von denen aus es gültig ist, principals und Befehle hinterlegt werden, die ausgeführt werden dürfen.

Eine ziemlich geniale Geschichte.

Zum Angriffsvektor... Nun. Derzeit haben wir etoken im Einsatz. Die Begehrlichkeiten für Nitrokeys sind bei uns vorhanden, es großflächiger einzusetzen. Es gibt aber die unumstößliche Anforderung, dass ein Key nur mit Master-PIN zurückgesetzt werden können darf... daher schieden bisher sämtliche Anbieter außer etoken aus... Ich mein ja nur... es könnte durchaus sein, dass ihr euch durch das Fehlen dieses Features ordentlich Geschäft entgehen lasst... Wir sind sicher nicht die einzigen, die diese Anforderung haben.

@nitrokey Wenn ein Computer kompromittiert ist... ja da hätte jeder ein Problem. In jedem größeren Unternehmen gibt es User die vor ihren PCs wie die ersten Menschen sitzen... und auf alles Klicken, was wie ein Link aussieht... ich hab noch kein Unternehmen erlebt, wo das anders war... Da nutzt die beste Schulung oft nix, weil diese MA dort dann pennen...

Und social engineering funktioniert leider immer wieder... vor allem, wenn es gut gemacht ist, und deine Organisation gezielt ausgewähltes Target eines solchen Angriffes ist... (Ich sage nur Stuxnet...)

Und wenn über so einen Angriff die Keys von Schlüssel-Arbeitskräften ausgeschaltet werden, dann kann der kompromittierte Rechner leicht in das ganze Netzwerk vordringen, ohne aufgehalten zu werden, da die Systeme nicht mehr per ssh erreichbar sind... weil die Keys zurückgesetzt wurden...

Ja, in Summe eine ziemlich ungute Situation. Vor allem wenn es Sicherheitsrelevante Systeme sind, die nicht einfach so abgedreht werden können...

Ich nehme an, per Firmware könnte man einen Master-PIN zum zurücksetzen sehr einfach einbauen.

@nitrokey ok.

ich hab mir einmal 2 der neuen Keys geordert und werde sie einmal selbst testen und den kollegen zeigen und darauf hinweisen, dass es die Möglichkeit gibt, eine eigene Lösung auch von euch zu bekommen.

Wäre sowas im Preis schon inbegriffen, oder müsste das extra bezahlt werden?

@nitrokey ok. Ohne dem Feature kommen die Nitrokeys bei uns nicht in Frage. Es stellt sich für uns dann die Frage, falls es das Feature gibt, ob bloß wir im Team auf Nitro-Keys umsteigen, das wären dann ~20 User.
Oder ob die gesamte Organisation eventuell umsteigen würde... das wären dann mehrere hundert Keys. Aber das liegt alles nicht in meiner Entscheidungskompetenz. Ich kann höchstens den Vorschlag machen und die Infos übermitteln.

@nitrokey ssh zertifikate sind ziemlich cool. Wenn man eine entsprechende PKI aufbaut, wären so Tages-Zertifikate oder Wochenzertifikate möglich, die man sich am Beginn der Periode abholt, und die automatisch ablaufen.

Vor allem erleichtert es den Tausch eines Tokens, wenn dieses kaputt oder verloren ging enorm. Es reicht einen neuen Token auszugeben, das Zertifikat per Email dem User zuzustellen und schon kann dieser mit dem neuen Key sich schon wieder einloggen, ohne einen einzigen Pubkey auszutauschen.

Die Revoke-List ist ein einfaches kleines Text-File mit den Seriennummern der widerrufenen Zertifikate, welches aus der CA exportiert werden muss und dann per ansible oder ähnlichen Mechanismen auf die Server auch im Nachhinein verteilt werden muss. Sowas kann man auch schön automatisieren...

Im Gegensatz dazu steht, dass man mit Pubkeys only auf jedem Host die authorized-keys-Datei aktualisieren muss. Und das kann bei vielen Servern per ansible schon eine schöne lange Zeit dauern.

@nitrokey Ich nutze zwar schon länger die Zertifikate, hab aber mangels HW-Token noch keine Erfahrung damit (Eure neuen Nitro-Keys werden meine ersten privaten sein - aktuell hab ich nur den etoken aus der Organisation im Einsatz, für die ich tätig bin). Und ich hab - muss ich gestehen - auch noch nicht wirklich Infos dazu gefunden, ob das Zertifikat auf den Key soll...

So wie in dieser Anleitung https://framkant.org/2017/07/scalable-access-control-using-openssh-certificates/ wird das Zertifikat im Filesystem abgelegt und per CertificateFile in der ssh-config oder über Commanline-Options eingebunden.

Meiner Meinung nach aber sollte das Zertifikat ja zum Private-Key - also auf den Token selbst. Und ich weiß nicht, ob ssh-agent oder gpg-agent in der lage sind, diese Zertifikate von dort auszulesen.

Momentan hab ich auch am derzeit eingesetzten etoken noch nicht geschafft, das Zertifikat abzulegen.