#pkcs11 — Public Fediverse posts

Jako začínající podnikatel potřebuji pravidelně podepisovat smlouvy kvalifikovaným podpisem. Certifikát jsem si uložil na čip eObčanky, jenže se ukázalo, že použitelný podepisovací software pro macOS prakticky neexistuje. Profesní vztek programátora vedl ke vzniku EasySigneru — bezplatné multiplatformní aplikace na .NET 8 a Avalonia UI. V tomto článku najdete nejen […]

Jako začínající podnikatel potřebuji pravidelně podepisovat smlouvy kvalifikovaným podpisem. Certifikát jsem si uložil na čip eObčanky, jenže se ukázalo, že použitelný podepisovací software pro macOS prakticky neexistuje. Profesní vztek programátora vedl ke vzniku EasySigneru — bezplatné multiplatformní aplikace na .NET 8 a Avalonia UI. V tomto článku najdete nejen […]

Jako začínající podnikatel potřebuji pravidelně podepisovat smlouvy kvalifikovaným podpisem. Certifikát jsem si uložil na čip eObčanky, jenže se ukázalo, že použitelný podepisovací software pro macOS prakticky neexistuje. Profesní vztek programátora vedl ke vzniku EasySigneru — bezplatné multiplatformní aplikace na .NET 8 a Avalonia UI. V tomto článku najdete nejen […]

Jako začínající podnikatel potřebuji pravidelně podepisovat smlouvy kvalifikovaným podpisem. Certifikát jsem si uložil na čip eObčanky, jenže se ukázalo, že použitelný podepisovací software pro macOS prakticky neexistuje. Profesní vztek programátora vedl ke vzniku EasySigneru — bezplatné multiplatformní aplikace na .NET 8 a Avalonia UI. V tomto článku najdete nejen […]

Jako začínající podnikatel potřebuji pravidelně podepisovat smlouvy kvalifikovaným podpisem. Certifikát jsem si uložil na čip eObčanky, jenže se ukázalo, že použitelný podepisovací software pro macOS prakticky neexistuje. Profesní vztek programátora vedl ke vzniku EasySigneru — bezplatné multiplatformní aplikace na .NET 8 a Avalonia UI. V tomto článku najdete nejen […]

Как защитить ключи LUKS с помощью Рутокен ЭЦП 3.0 и алгоритмов ГОСТ Р 34.10-2012. Часть 4

Безопасная эксплуатация ноутбуков, или Защита пользовательского ключа с помощью алгоритмов ГОСТ Р 34.10-2012 В третьей части мы настроили защиту мастер-ключа с помощью USB-токена, используя RSA, но теперь мы перейдем на алгоритмы ГОСТ Р 34.10-2012. Жаркие. Зимние. Твои. А еще они основаны на более перспективных эллиптических кривых, которым не нужны такие большие ключи, чтобы обеспечить более высокий уровень безопасности.

https://habr.com/ru/companies/aktiv-company/articles/996516/

#linux #luks #полнодисковое_шифрование #рутокен #plymouth #openssl #pkcs11 #encrypt #bitlocker #гост_34102012

Как защитить ключи LUKS с помощью Рутокен ЭЦП 3.0 и алгоритмов ГОСТ Р 34.10-2012. Часть 3

Безопасная эксплуатация ноутбуков, или Защита пользовательского ключа с помощью USB-токена на примере Рутокен ЭЦП 3.0 Из второй части мы узнали, как настроить загрузку компьютера таким образом, чтобы для разблокирования системного диска использовались ключи, размещенные на внешнем USB-накопителе. Однако при краже компьютера вместе с этим накопителем злоумышленник сможет получить доступ к данным так, как если бы они не были защищены вовсе, поэтому наиболее привлекательным способом решения поставленной задачи видится использование USB-токенов и смарт-карт, таких как Рутокен ЭЦП 3.0 или JaCarta-2 ГОСТ. Токены представляют собой защищенные микроконтроллеры со встроенной энергонезависимой памятью, поэтому способны выполнять все вычисления самостоятельно без использования ресурсов центрального процессора, не допуская копирование закрытого ключа с устройства, что обеспечивает максимально высокий уровень безопасности.

https://habr.com/ru/companies/aktiv-company/articles/994834/

#linux #luks #полнодисковое_шифрование #рутокен #plymouth #rsa #openssl #pkcs11 #encrypt #bitlocker

There are three new guides around Crypto and Linux on IBM Z.
You can find the publication here:
Set up openCryptoki : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-apache-http-server-pkcs11-providers

Set up an Apache HTTP Server with PKCS#11 providers : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-apache-http-server-pkcs11-providers

Set up an nginx web server with PKCS#11 providers : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-nginx-web-server-pkcs11-providers

#ibm #linux #linuxonZ #ibmz #crypto #pkcs11

There are three new guides around Crypto and Linux on IBM Z.
You can find the publication here:
Set up openCryptoki : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-apache-http-server-pkcs11-providers

Set up an Apache HTTP Server with PKCS#11 providers : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-apache-http-server-pkcs11-providers

Set up an nginx web server with PKCS#11 providers : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-nginx-web-server-pkcs11-providers

#ibm #linux #linuxonZ #ibmz #crypto #pkcs11

There are three new guides around Crypto and Linux on IBM Z.
You can find the publication here:
Set up openCryptoki : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-apache-http-server-pkcs11-providers

Set up an Apache HTTP Server with PKCS#11 providers : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-apache-http-server-pkcs11-providers

Set up an nginx web server with PKCS#11 providers : https://www.ibm.com/docs/en/solution-assurance?topic=security-set-up-nginx-web-server-pkcs11-providers

#ibm #linux #linuxonZ #ibmz #crypto #pkcs11

#Ubuntu24 verweigerte heute nach einem Reboot die Nutzung meines #Yubikeys.
Ich konnte mich als mit #pkcs11 nicht mehr an meinen Servern per ssh anmelden.

Eine hängengebliebene Filesystem-Action eines Remote-Filesystems verhinderte offenbar, dass Linux meinen Laptop nicht schlafen schicken konnte... Totem ließ sich nicht beenden vom Kernel... aber das ist eine andere Geschichte. Jedenfalls schaltete sich mein Laptop nicht ab bis der Akku leer war.

In einem Anfall seniler Bettflucht hab ich meinen Laptop hergenommen und wollte checken, warum Friendica nur mehr blurred Vorschaubilder anzeigt (Spoiler, das Debuglog eines anderen Services füllte mir die Platte an...) und mein ssh-agent verweigerte das Hinzufügen des Yubikeys. Standhaft.

Ein Blick ins Journal ergab dann folgende Seltsamkeit:

Sep 12 04:34:02 AET-1931 pcscd[24807]: 99999999 auth.c:143:IsClientAuthorized() Process 36310 (user: 2000) is NOT authorized for action: access_pcsc
Sep 12 04:34:02 AET-1931 pcscd[24807]: 00000197 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC client

Ein Restart von pcscd brachte keine Erlösung.
Ein Reboot übrigens auch nicht.

Also weitersuchen. Aufgrund der Recherchen einmal

opensc-tool --list-readers
No smart card readers found.

Shice... und was sagt gpg?

gpg --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Das Journal dazu befragt... scdaemon erkennt meine Smartcards, aber pcscd verweigert meinem User den Zugriff.

Also mal als Root... ja, da liefert opensc-tool meine Smartcards.

Dann eine noch seltsamere Erkenntnis...
In tmux ausgeführt, verweigert pcscd die Abfrage mit opensc-tool, in der normalen Bash gibts aber ein Ergebnis... meine Token sind da.

Dann hab ich meinen SafeNet eToken ausprobiert... der ließ sich wunderbar zum ssh-agent hinzufügen... gut, der nutzt aber auch den scdaemon bzw. pcscd nicht (extra Ausnahme in der Config).

Schließlich wurde ich auf bugs.debian.org/cgi-bin/bugrep… fündig. Offenbar wurden bei Polkit Rules entfernt, die es Usern erlauben, pcscd/Smartcards zu nutzen... am 8. September beim Update wurde /usr/share/polkit-1/rules.d/sssd-pcsc.rules so geändert, dass die Rule nur mehr für Root zieht. Da wurde das File zumindest aktualisert.
Und heut erst wurde die Änderung durch den Zwangsreboot schlagend...

Die Lösung war auf jeden Fall folgende:
Ich hab ein File /etc/polkit-1/rules.d/40-allow-pcscd.rules

# cat 40-allow-pcscd.rules 
polkit.addRule(function(action, subject) {
    if (
        subject.isInGroup("plugdev")
        && (
            action.id === "org.debian.pcsc-lite.access_pcsc"
            || action.id === "org.debian.pcsc-lite.access_card"
        )
    ) {
        return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

Aber warum gpg am Yubikey nicht mehr funktioniert... bleibt mir auch ein Rätsel.

#Ubuntu24 verweigerte heute nach einem Reboot die Nutzung meines #Yubikeys.
Ich konnte mich als mit #pkcs11 nicht mehr an meinen Servern per ssh anmelden.

Eine hängengebliebene Filesystem-Action eines Remote-Filesystems verhinderte offenbar, dass Linux meinen Laptop nicht schlafen schicken konnte... Totem ließ sich nicht beenden vom Kernel... aber das ist eine andere Geschichte. Jedenfalls schaltete sich mein Laptop nicht ab bis der Akku leer war.

In einem Anfall seniler Bettflucht hab ich meinen Laptop hergenommen und wollte checken, warum Friendica nur mehr blurred Vorschaubilder anzeigt (Spoiler, das Debuglog eines anderen Services füllte mir die Platte an...) und mein ssh-agent verweigerte das Hinzufügen des Yubikeys. Standhaft.

Ein Blick ins Journal ergab dann folgende Seltsamkeit:

Sep 12 04:34:02 AET-1931 pcscd[24807]: 99999999 auth.c:143:IsClientAuthorized() Process 36310 (user: 2000) is NOT authorized for action: access_pcsc
Sep 12 04:34:02 AET-1931 pcscd[24807]: 00000197 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC client

Ein Restart von pcscd brachte keine Erlösung.
Ein Reboot übrigens auch nicht.

Also weitersuchen. Aufgrund der Recherchen einmal

opensc-tool --list-readers
No smart card readers found.

Shice... und was sagt gpg?

gpg --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Das Journal dazu befragt... scdaemon erkennt meine Smartcards, aber pcscd verweigert meinem User den Zugriff.

Also mal als Root... ja, da liefert opensc-tool meine Smartcards.

Dann eine noch seltsamere Erkenntnis...
In tmux ausgeführt, verweigert pcscd die Abfrage mit opensc-tool, in der normalen Bash gibts aber ein Ergebnis... meine Token sind da.

Dann hab ich meinen SafeNet eToken ausprobiert... der ließ sich wunderbar zum ssh-agent hinzufügen... gut, der nutzt aber auch den scdaemon bzw. pcscd nicht (extra Ausnahme in der Config).

Schließlich wurde ich auf bugs.debian.org/cgi-bin/bugrep… fündig. Offenbar wurden bei Polkit Rules entfernt, die es Usern erlauben, pcscd/Smartcards zu nutzen... am 8. September beim Update wurde /usr/share/polkit-1/rules.d/sssd-pcsc.rules so geändert, dass die Rule nur mehr für Root zieht. Da wurde das File zumindest aktualisert.
Und heut erst wurde die Änderung durch den Zwangsreboot schlagend...

Die Lösung war auf jeden Fall folgende:
Ich hab ein File /etc/polkit-1/rules.d/40-allow-pcscd.rules

# cat 40-allow-pcscd.rules 
polkit.addRule(function(action, subject) {
    if (
        subject.isInGroup("plugdev")
        && (
            action.id === "org.debian.pcsc-lite.access_pcsc"
            || action.id === "org.debian.pcsc-lite.access_card"
        )
    ) {
        return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

Aber warum gpg am Yubikey nicht mehr funktioniert... bleibt mir auch ein Rätsel.

#Ubuntu24 verweigerte heute nach einem Reboot die Nutzung meines #Yubikeys.
Ich konnte mich als mit #pkcs11 nicht mehr an meinen Servern per ssh anmelden.

Eine hängengebliebene Filesystem-Action eines Remote-Filesystems verhinderte offenbar, dass Linux meinen Laptop nicht schlafen schicken konnte... Totem ließ sich nicht beenden vom Kernel... aber das ist eine andere Geschichte. Jedenfalls schaltete sich mein Laptop nicht ab bis der Akku leer war.

In einem Anfall seniler Bettflucht hab ich meinen Laptop hergenommen und wollte checken, warum Friendica nur mehr blurred Vorschaubilder anzeigt (Spoiler, das Debuglog eines anderen Services füllte mir die Platte an...) und mein ssh-agent verweigerte das Hinzufügen des Yubikeys. Standhaft.

Ein Blick ins Journal ergab dann folgende Seltsamkeit:

Sep 12 04:34:02 AET-1931 pcscd[24807]: 99999999 auth.c:143:IsClientAuthorized() Process 36310 (user: 2000) is NOT authorized for action: access_pcsc
Sep 12 04:34:02 AET-1931 pcscd[24807]: 00000197 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC client

Ein Restart von pcscd brachte keine Erlösung.
Ein Reboot übrigens auch nicht.

Also weitersuchen. Aufgrund der Recherchen einmal

opensc-tool --list-readers
No smart card readers found.

Shice... und was sagt gpg?

gpg --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Das Journal dazu befragt... scdaemon erkennt meine Smartcards, aber pcscd verweigert meinem User den Zugriff.

Also mal als Root... ja, da liefert opensc-tool meine Smartcards.

Dann eine noch seltsamere Erkenntnis...
In tmux ausgeführt, verweigert pcscd die Abfrage mit opensc-tool, in der normalen Bash gibts aber ein Ergebnis... meine Token sind da.

Dann hab ich meinen SafeNet eToken ausprobiert... der ließ sich wunderbar zum ssh-agent hinzufügen... gut, der nutzt aber auch den scdaemon bzw. pcscd nicht (extra Ausnahme in der Config).

Schließlich wurde ich auf bugs.debian.org/cgi-bin/bugrep… fündig. Offenbar wurden bei Polkit Rules entfernt, die es Usern erlauben, pcscd/Smartcards zu nutzen... am 8. September beim Update wurde /usr/share/polkit-1/rules.d/sssd-pcsc.rules so geändert, dass die Rule nur mehr für Root zieht. Da wurde das File zumindest aktualisert.
Und heut erst wurde die Änderung durch den Zwangsreboot schlagend...

Die Lösung war auf jeden Fall folgende:
Ich hab ein File /etc/polkit-1/rules.d/40-allow-pcscd.rules

# cat 40-allow-pcscd.rules 
polkit.addRule(function(action, subject) {
    if (
        subject.isInGroup("plugdev")
        && (
            action.id === "org.debian.pcsc-lite.access_pcsc"
            || action.id === "org.debian.pcsc-lite.access_card"
        )
    ) {
        return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

Aber warum gpg am Yubikey nicht mehr funktioniert... bleibt mir auch ein Rätsel.

#Ubuntu24 verweigerte heute nach einem Reboot die Nutzung meines #Yubikeys.
Ich konnte mich als mit #pkcs11 nicht mehr an meinen Servern per ssh anmelden.

Eine hängengebliebene Filesystem-Action eines Remote-Filesystems verhinderte offenbar, dass Linux meinen Laptop nicht schlafen schicken konnte... Totem ließ sich nicht beenden vom Kernel... aber das ist eine andere Geschichte. Jedenfalls schaltete sich mein Laptop nicht ab bis der Akku leer war.

In einem Anfall seniler Bettflucht hab ich meinen Laptop hergenommen und wollte checken, warum Friendica nur mehr blurred Vorschaubilder anzeigt (Spoiler, das Debuglog eines anderen Services füllte mir die Platte an...) und mein ssh-agent verweigerte das Hinzufügen des Yubikeys. Standhaft.

Ein Blick ins Journal ergab dann folgende Seltsamkeit:

Sep 12 04:34:02 AET-1931 pcscd[24807]: 99999999 auth.c:143:IsClientAuthorized() Process 36310 (user: 2000) is NOT authorized for action: access_pcsc
Sep 12 04:34:02 AET-1931 pcscd[24807]: 00000197 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC client

Ein Restart von pcscd brachte keine Erlösung.
Ein Reboot übrigens auch nicht.

Also weitersuchen. Aufgrund der Recherchen einmal

opensc-tool --list-readers
No smart card readers found.

Shice... und was sagt gpg?

gpg --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Das Journal dazu befragt... scdaemon erkennt meine Smartcards, aber pcscd verweigert meinem User den Zugriff.

Also mal als Root... ja, da liefert opensc-tool meine Smartcards.

Dann eine noch seltsamere Erkenntnis...
In tmux ausgeführt, verweigert pcscd die Abfrage mit opensc-tool, in der normalen Bash gibts aber ein Ergebnis... meine Token sind da.

Dann hab ich meinen SafeNet eToken ausprobiert... der ließ sich wunderbar zum ssh-agent hinzufügen... gut, der nutzt aber auch den scdaemon bzw. pcscd nicht (extra Ausnahme in der Config).

Schließlich wurde ich auf bugs.debian.org/cgi-bin/bugrep… fündig. Offenbar wurden bei Polkit Rules entfernt, die es Usern erlauben, pcscd/Smartcards zu nutzen... am 8. September beim Update wurde /usr/share/polkit-1/rules.d/sssd-pcsc.rules so geändert, dass die Rule nur mehr für Root zieht. Da wurde das File zumindest aktualisert.
Und heut erst wurde die Änderung durch den Zwangsreboot schlagend...

Die Lösung war auf jeden Fall folgende:
Ich hab ein File /etc/polkit-1/rules.d/40-allow-pcscd.rules

# cat 40-allow-pcscd.rules 
polkit.addRule(function(action, subject) {
    if (
        subject.isInGroup("plugdev")
        && (
            action.id === "org.debian.pcsc-lite.access_pcsc"
            || action.id === "org.debian.pcsc-lite.access_card"
        )
    ) {
        return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

Aber warum gpg am Yubikey nicht mehr funktioniert... bleibt mir auch ein Rätsel.

#Ubuntu24 verweigerte heute nach einem Reboot die Nutzung meines #Yubikeys.
Ich konnte mich als mit #pkcs11 nicht mehr an meinen Servern per ssh anmelden.

Eine hängengebliebene Filesystem-Action eines Remote-Filesystems verhinderte offenbar, dass Linux meinen Laptop nicht schlafen schicken konnte... Totem ließ sich nicht beenden vom Kernel... aber das ist eine andere Geschichte. Jedenfalls schaltete sich mein Laptop nicht ab bis der Akku leer war.

In einem Anfall seniler Bettflucht hab ich meinen Laptop hergenommen und wollte checken, warum Friendica nur mehr blurred Vorschaubilder anzeigt (Spoiler, das Debuglog eines anderen Services füllte mir die Platte an...) und mein ssh-agent verweigerte das Hinzufügen des Yubikeys. Standhaft.

Ein Blick ins Journal ergab dann folgende Seltsamkeit:

Sep 12 04:34:02 AET-1931 pcscd[24807]: 99999999 auth.c:143:IsClientAuthorized() Process 36310 (user: 2000) is NOT authorized for action: access_pcsc
Sep 12 04:34:02 AET-1931 pcscd[24807]: 00000197 winscard_svc.c:355:ContextThread() Rejected unauthorized PC/SC client

Ein Restart von pcscd brachte keine Erlösung.
Ein Reboot übrigens auch nicht.

Also weitersuchen. Aufgrund der Recherchen einmal

opensc-tool --list-readers
No smart card readers found.

Shice... und was sagt gpg?

gpg --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Das Journal dazu befragt... scdaemon erkennt meine Smartcards, aber pcscd verweigert meinem User den Zugriff.

Also mal als Root... ja, da liefert opensc-tool meine Smartcards.

Dann eine noch seltsamere Erkenntnis...
In tmux ausgeführt, verweigert pcscd die Abfrage mit opensc-tool, in der normalen Bash gibts aber ein Ergebnis... meine Token sind da.

Dann hab ich meinen SafeNet eToken ausprobiert... der ließ sich wunderbar zum ssh-agent hinzufügen... gut, der nutzt aber auch den scdaemon bzw. pcscd nicht (extra Ausnahme in der Config).

Schließlich wurde ich auf bugs.debian.org/cgi-bin/bugrep… fündig. Offenbar wurden bei Polkit Rules entfernt, die es Usern erlauben, pcscd/Smartcards zu nutzen... am 8. September beim Update wurde /usr/share/polkit-1/rules.d/sssd-pcsc.rules so geändert, dass die Rule nur mehr für Root zieht. Da wurde das File zumindest aktualisert.
Und heut erst wurde die Änderung durch den Zwangsreboot schlagend...

Die Lösung war auf jeden Fall folgende:
Ich hab ein File /etc/polkit-1/rules.d/40-allow-pcscd.rules

# cat 40-allow-pcscd.rules 
polkit.addRule(function(action, subject) {
    if (
        subject.isInGroup("plugdev")
        && (
            action.id === "org.debian.pcsc-lite.access_pcsc"
            || action.id === "org.debian.pcsc-lite.access_card"
        )
    ) {
        return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

Aber warum gpg am Yubikey nicht mehr funktioniert... bleibt mir auch ein Rätsel.

Siamo nel #2025 e con #Firefox sulle *buntu #Opensc e tutti i certificati #PKCS11 (quindi anche robe come la #CNS) continuano a *NON* funzionare grazie al fantastico sistema #SNAP che qualcuno nello staff di #Ubuntu ha detto semplicemente "freghiamocene", nonostante sia stato segnalato da ANNI il problema

Vediamo quanti anni devono passare ancora... Io sono senza parole 😞

Siamo nel #2025 e con #Firefox sulle *buntu #Opensc e tutti i certificati #PKCS11 (quindi anche robe come la #CNS) continuano a *NON* funzionare grazie al fantastico sistema #SNAP che qualcuno nello staff di #Ubuntu ha detto semplicemente "freghiamocene", nonostante sia stato segnalato da ANNI il problema

Vediamo quanti anni devono passare ancora... Io sono senza parole 😞

Are you using #SoftHSM? Join us on October 24th! Check the attachment for details.

#PKI #PKCS11 #SOFTHSM #OPENDNSSEC #OPENSOURCE

Are you using #SoftHSM? Join us on October 24th! Check the attachment for details.

#PKI #PKCS11 #SOFTHSM #OPENDNSSEC #OPENSOURCE

Morgen, am 14.06.2024 um 18:30 gibt es wieder ein #VALUG-Treffen im Alten Schl8hof in #Wels. @hkrat wird diesmal Einblicke in die Thematik "#HSM (#TPM, #CAAM) & #PKCS11" gewähren. https://valug.at/events/2024-06-14-hsm/

Morgen, am 14.06.2024 um 18:30 gibt es wieder ein #VALUG-Treffen im Alten Schl8hof in #Wels. @hkrat wird diesmal Einblicke in die Thematik "#HSM (#TPM, #CAAM) & #PKCS11" gewähren. https://valug.at/events/2024-06-14-hsm/

Morgen, am 14.06.2024 um 18:30 gibt es wieder ein #VALUG-Treffen im Alten Schl8hof in #Wels. @hkrat wird diesmal Einblicke in die Thematik "#HSM (#TPM, #CAAM) & #PKCS11" gewähren. https://valug.at/events/2024-06-14-hsm/

Morgen, am 14.06.2024 um 18:30 gibt es wieder ein #VALUG-Treffen im Alten Schl8hof in #Wels. @hkrat wird diesmal Einblicke in die Thematik "#HSM (#TPM, #CAAM) & #PKCS11" gewähren. https://valug.at/events/2024-06-14-hsm/

從一開始入手 … 閱讀全文 Fedora 上使用硬體加密的 SSH 與 PGP

https://kanru.info/fedora-pkcs11-ssh-and-pgp/

從一開始入手 … 閱讀全文 Fedora 上使用硬體加密的 SSH 與 PGP

https://kanru.info/fedora-pkcs11-ssh-and-pgp/

從一開始入手 … 閱讀全文 Fedora 上使用硬體加密的 SSH 與 PGP

https://kanru.info/fedora-pkcs11-ssh-and-pgp/

從一開始入手 … 閱讀全文 Fedora 上使用硬體加密的 SSH 與 PGP

https://kanru.info/fedora-pkcs11-ssh-and-pgp/

While exploring use of PKCS #11 devices in #OpenPGP contexts, I stumbled over a bug (and potential security issue) in the yubihsm_pkcs11.so driver for #YubiHSM devices.

Long form text by Christian Reitter (who walked me through the coordinated disclosure process with #Yubico, and did amazing work analyzing and writing up the issue):
https://blog.inhq.net/posts/yubico-yubihsm-pkcs-vuln/

Yubico advisory: https://www.yubico.com/support/security-advisories/ysa-2023-01/

#CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39908

(Thanks again to @sovtechfund for funding my #PKCS11 work)

Over the last half year, I've spent time with PKCS #11 and PIV hardware security devices. In particular, using such devices in the #OpenPGP context.

Entry points for results of this work:

- https://codeberg.org/heiko/openpgp-pkcs11
- https://codeberg.org/heiko/openpgp-piv
- https://codeberg.org/heiko/pkcs11-openpgp-notes

One particular focus was building CI testing infrastructure (including https://gitlab.com/hkos/virtual-piv/), to make future work on these codebases easier (and hopefully fun).

#PKCS11 #PIV #HSM

[This work was funded by @sovtechfund]

OASIS Open is a cosponsor of this year's International Cryptographic Module Conference (#ICMC23) in Ottawa this September; two of our technical committees, #KMIP and #PKCS11, are on the agenda.
More details: https://icmconference.org
#cryptography #security #standards

RT @[email protected]: Agenda Announced! The Industry Reconvenes this Fall in Ottawa to Review Changing Global Standards ... in commercial cryptography.

OASIS Open is a cosponsor of this year's International Cryptographic Module Conference (#ICMC23) in Ottawa this September; two of our technical committees, #KMIP and #PKCS11, are on the agenda.
More details: https://icmconference.org
#cryptography #security #standards

RT @[email protected]: Agenda Announced! The Industry Reconvenes this Fall in Ottawa to Review Changing Global Standards ... in commercial cryptography.

Today I spent a bit of time with the #YubiHSM and its #PKCS11 driver (the yubihsm_pkcs11.so driver had exhibited some confusing-to-me behavior, during occasional experiments over the past few weeks).

After a closer look, I believe that "yubihsm_pkcs11.so" version 2.4.0 has introduced a number of rather confusing regressions around object IDs (see https://github.com/Yubico/yubihsm-shell/issues/345 #Yubico).

This investigation was a side-quest of my @sovtechfund financed project "PKCS#11 support for @sequoiapgp".

As the adoption of Delegated and Hybrid #RPKI grows, so are the number of Hardware Security Modules (HSMs) out in the field that people store Krill's key material on.

#KMIP is pretty straight forward, but especially #PKCS11 can be quite finicky. So we're keeping a public list of interoperability information. #BGP #OpenSource #interop #rustlang https://github.com/NLnetLabs/krill/issues?q=label%3A%22interop+testing%22+label%3A%22hsm%22

Learn more about the option to use HSMs here: https://krill.docs.nlnetlabs.nl/en/stable/hsm.html

When playing with my #Yubi 5 key, I have hit a wall. OTP keys were not straight forward, but worked. #PKCS11 works fine. But moving secret key from #gpg to the key became blocker. It just doesn't work! Gitlab's or GitHub's #fido works like charm though.