@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.
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.
@levin @kuketzblog Den Nitrokey HSM brauchst du für die CA. Wenn du es genau nimmst, bräuchtest du eigentlich 2 solcher HSMs weil du sinnvollerweise 2 CAs betreibst. Eine für die Hostkeys, welche von den Sysadmins verwatet wird, und eine für die User-Keys, welche von der z.B. Personalverwaltung verwaltet wird, die auch die HW-Tokens für die Mitarbeiter ausgibt.
Auf die Rechner der User kommt das CA-Zertifikat der Hostkey-CA, auf die Server kommt das CA-Zertifikat der User-CA (und zusätlich das Zertifikat des Hostkeys)
Jeder User bekommt mit dem Token auch sein persönliches Zertifikat ausgegeben, welches er dann zwingend zur Authentifizierung benötigt.
Auf die Rechner der User kommt das CA-Zertifikat der Hostkey-CA, auf die Server kommt das CA-Zertifikat der User-CA (und zusätlich das Zertifikat des Hostkeys)
Jeder User bekommt mit dem Token auch sein persönliches Zertifikat ausgegeben, welches er dann zwingend zur Authentifizierung benötigt.
@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)
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)
@levin @kuketzblog Ein "relativ" neues und leider noch sehr unbekanntes Feature von openssh.
https://chandanduttachowdhury.wordpress.com/2014/12/31/certificate-based-ssh-user-authentication/
https://ef.gy/hardening-ssh
Ziemlich geniale Geschichte.
https://chandanduttachowdhury.wordpress.com/2014/12/31/certificate-based-ssh-user-authentication/
https://ef.gy/hardening-ssh
Ziemlich geniale Geschichte.
@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?
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?
@kuketzblog schaut prinzipiell gut aus.
Ich frag mich nur, wie man ssh-Zertifikate (nein nicht die Pubkeys!!!) am besten handelt, und ob die auch auf den Stick sollen, und vor allem können???
Derzeit hab ich die Zertifikate als Software-certs am Rechner liegen, was mich nicht so freut...
Ich frag mich nur, wie man ssh-Zertifikate (nein nicht die Pubkeys!!!) am besten handelt, und ob die auch auf den Stick sollen, und vor allem können???
Derzeit hab ich die Zertifikate als Software-certs am Rechner liegen, was mich nicht so freut...
@kuketzblog @beedaddy ich hab ges chaut, ein Gerät hat nur USB-A... also wirds der A-Keiy mit A2C-Adapter
Ein föderiertes Git würd ich noch sehr cool finden. Also gitlab oder gitea mit ActivityPub, damit man auch auf fremden Servern folgen, forken, kommentieren, voten oder gar Pull/Pushrequests absetzen kann..., so als ob es auf einem Server wär.
Gestern übernahm der Konzern Strabag die Baustelle im #Danni, um mit den Bauarbeiten für die Autobahntrasse der A49 zu beginnen. Ein großer Fehler.
Deshalb hat die Attac Jugendgruppe "attacikka Damstadt" den Auftakt für unsere Aktionswoche gegen den Bau der A49 und allen weiteren unsinnigen Autobahnbauprojekten gelegt und dieses Banner in der Nähe eines Stabag Standortes aufgehängt.
Der Kampf geht weiter noch steht #keineA49!
Überwachungshorst und SPD fordern #Identifizierungszwang für Messenger und E-Mail-Konten bzw. soziale Netzwerke.
Unverantwortlich: Identität und Privatanschrift sind nicht sicher in den Händen von Facebook, Google und Co.! Nur #Anonymität im Netz schützt wirksam vor Datenklau und Datenverlust, Stalking und Identitätsdiebstahl! Besonders wichtig z.B. für Frauen, Kinder, Minderheiten und gefährdete Personen, Missbrauchs- und Stalkingopfer, Aktivisten und Whistleblower. https://geekfeminism.wikia.org/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F
@bicycle @digitalcourage würde das für mich mit meinen Hetzner-Servern wohl auch schlagend werden.
Auch wenn die in Helsinki stehen?
Auch wenn die in Helsinki stehen?
@ViennaForFuture hallo. Ich las auf Facebook (noch.... bin ich dort) vom Klimastreik.
In dem Zusammenhng wollt ich euch auf Mobilizon aufmerksam machen. Das ist eine Eventorganisationsplattform aus dem Fediverse.
https://joinmobilizon.org/de/
Ist ähnlich rinfach selbst zu hosten wie Pleroma oder Mastodon.
Framasoft entwickelt da grad ganz intensiv. Ich hab mir mal eine Instanz aufgesetzt. https://events.schuerz.at
Wär für euch sicher auch eine gute Idee. Vor allem um auch Leute ohne Facbook abzuholen.
In dem Zusammenhng wollt ich euch auf Mobilizon aufmerksam machen. Das ist eine Eventorganisationsplattform aus dem Fediverse.
https://joinmobilizon.org/de/
Ist ähnlich rinfach selbst zu hosten wie Pleroma oder Mastodon.
Framasoft entwickelt da grad ganz intensiv. Ich hab mir mal eine Instanz aufgesetzt. https://events.schuerz.at
Wär für euch sicher auch eine gute Idee. Vor allem um auch Leute ohne Facbook abzuholen.
Mass surveillance around the world is growing. We have to fight for our right to privacy and freedom of speech! Here we explain how any backdoor would lessen security for all of us: https://tutanota.com/blog/posts/why-a-backdoor-is-a-security-risk
Die wahren Künstler der Modellbahn ❤️
@kuketzblog Ob man da nachträglich auch noch eine Löschung beantragen kann? Und vor allem WIE?
@kuketzblog Soweit ich das bei der Löschung noch in Erinnerung habe, wurde geschrieben, dass alle Daten und Datensicherungen gelöscht werden... Dachte, das wäre so ausreichend... hab aber leider nicht weiter hinterfragt.