Technische Fragen

Ja, auf dem Markt sind verschiedene Libraries vorhanden, die eine schnelle Implementierung einer Teilnehmerapplikation ermöglichen. Alle haben speziell auch für den Swisscom Service einen besonderen Support:

• Intarsys, Deutschland: stellt verschiedene Lösungen zur Verfügung zum Handling und Einbindung von Signaturen: https://www.intarsys.de/produkte/fernsignatur

Intarsys ist Premium-Partner der Swisscom und kennt technisch den AIS Service sehr gut und kann hier im Consulting unterstützen.

• PDF-Tools, Schweiz: 3-Heights PDF Suite. http://www.pdf-tools.com/pdf20/de/produkte/pdf-security-signature/pdf-security/
• iText, Belgien: https://itextpdf.com/de/products/product-tour. Swisscom nutzt in seinen Beispielen iText, allerdings sind die Beispiele “out of date”, d.h. einige Funktionalitäten haben sich geändert. Aber das prinzipielle Handling ist dort ersichtlich: https://github.com/SCS-CBU-CED-IAM/itext-ais
• Setasign, Deutschland: Einige Kunden setzen SetaPDF ein, welche spezielle Lösung auch für den Swisscom Service bietet: https://www.setasign.com/products/setapdf-signer/demos/swisscom-all-in-signing-service/
• Blocksigner, Schweiz (Skribble.com): https://api.skribble.com/swagger-ui.html

Grundsätzlich lehnt Swisscom jegliche Verantwortung für das Funktionieren dieser Libraries ab. Diese können Fehler enthalten und bedürfen besonderes Wissen und Fachkenntnisse. Die Verwendung geschieht auf eigene Verantwortung durch den Teilnehmer.

Nein. Swisscom hat sogar die Auflage, bei der Einbindung des PWD/OTP Screens als “iFrame” eine Möglichkeit zu geben, dass eine externe Person prüfen kann, dass diese von Swisscom stammt. Hier können z.B. die Standard Browser Funktionen genutzt werden, die Swisscom unter seinem Webseitenlink gemäss Kapitel 4 der Nutzungsbestimmungen publiziert. Weitere Informationen auch hier: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide 

Nein, siehe Anleitung unter https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Ja. Allerdings nur als iFrame, siehe Anleitung unter https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Ja. Im Rahmen des Protokolls kann, wie im Reference Guide (www.swisscom.com/signing-service ) unter “Step-Up Methode” beschrieben, im “Message” Feld der Textblock mit der Überschrift zur Nachricht für die Willensbekundung und mit “Language” die Spracheinstellung konfiguriert werden. Für das SMS Eingabefenster kann ebenfalls die Sprache mit dem “Language” Parameter eingestellt werden.

Grundsätzlich dient der verifyCall dazu, zu prüfen, ob ein Signierender bereits registriert ist. Wählt man im verify call das Pseudonym, so reicht die Angabe von Land und Mobilnummer.

https://documents.swisscom.com/product/filestore/lib/4cce2074-46e3-4e43-a1b4-ccf5d5cb7ca5/VerifyID4Signing-de.pdf

Screen Scrapping wird als Interface nicht unterstützt. Entwickler müssen damit rechnen, dass die Screens verändert werden. Zudem widerspricht es dem “Sole Control” Gedanken des direkten Zugriffs des Signierenden auf das Unterschriftenzertifikat. Weitere Informationen zur Einbettung eines iFrames auch hier: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Im Prinzip ja. Sofern im Signaturzertifikat genau der Name erscheinen soll, wie im Ausweisdokument, muss auch die Anfrage den genauen Namen mit allen Zunamen wie im amtlichen Dokument enthalten. Wenn das zu aufwändig ist, kann das “Template” Feature genutzt werden (https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Distinguished-Name:-Use-of-Evidence-Attributes). Es ermöglicht die exakte Übernahme des Namens, Vornamens etc. so wie dieser im RA-Service (SRS) abgespeichert wurde.

Swisscom kann den Dienst aber auch so konfigurieren, dass anstelle des Namens im Zertifikat die Mobilnummer als Pseudonym genommen wird. Es steht dann weiterhin dem Anwender frei im “Common Name” (CN) den gewöhnlichen Vor- und Zunamen (unabhängig vom Ausweisdokument) zu nutzen. Der RA-Service VerifyCall verifiziert in diesem Falle nur die Mobilnummer, die während der Identifikation angegeben wurde und das Heimatland gemäss Ausweisdokument. Die Nutzung des Pseudonyms im VerifyCall ist unabhängig davon, ob das Pseudonym auch im Signing Request genutzt wurde.

Das Zugangszertifikat kann ein selbst signiertes Zertifikat sein. Beispielweise mit openssl Software.

Anforderungen an den Distinguished Name:

• CN=<URL des Teilnehmersystems, welches die Kommunikation mit AIS durchführt oder andere eindeutige Identifikation des Teilnehmersystems>
• O=<Name der Organisation>
• Email=<E-Mail Adresse für Informationen am Ende des Gültigkeitszeitraumes>
• C=<Land der Organisation>

Folgende weitere Anforderungen sind bei der Erstellung des Zertifikates zu berücksichtigen:

• Maximale Laufzeit 3 Jahre
• Hashalgorithmus minimum SHA-256
• Key length minimum 3072 bit

Für Zugangszertifikate im Rahmen der geregelten (ZertES) oder qualifizierten (eIDAS) Siegelerstellung gelten noch besondere Bedingungen: Der private Schlüssel des Zugangszertifikates muss in einer gemeinsamen Zeremonie eines Registrierungsstellenvertreters von Swisscom auf einem kryptographischen Modul erstellt werden. Dieses Modul muss den Anforderungen an FIPS 140-2 level 2 entsprechen oder ähnlichen Sicherheitsstufen, z.B. Yubikey, Feitan Key oder Microsoft Key Vault. Alternativ kann auch ein Konzept eingereicht werden, wie die Zuordnung des Zugangszertifikates zum Verantwortlichen der Organisation anderweitig erzielt werden kann.

Die Einbettung von signierten Hashes sollte man PDF Spezialisten oder entsprechenden Libraries überlassen. Der Platz für die Signatur muss vorausberechnet werden (siehe hierzu https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4).

Eine folgende Lösung kann eine Lösung bieten. Diese stellen wir hier ohne Garantie vor, da Swisscom sich nur auf den Service und nicht auf die Signaturapplikation fokussiert:

• Erzeuge ein PDF mit leerem und vorausgefülltem Signaturfeld
• Der Byterange sollte mit Nullen bis zur erwarteten Grösse gefüllt werden
• Bilde den Hash des Dokumentes
• Signiere den Hash mit dem All-in Signing Service
• Fülle den signierten Hash in das leere Signaturfeld
• Iteriere bis zum leeren Signaturfeld
• Ermittele den Byte range des leeren Signaturfeldes
• Berechne den Offset des byte range
• Öffne das Dokument mit dem leeren Signaturfeld im read-write mode und suche den Offset, wo der Hash eingefügt wurde

Wichtig ist auch die Einhaltung des PADES Standards und der LTV Vorgaben. Siehe hierzu https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation

Es gibt einen Test- und Demomode, mit dem man die App ausprobieren kann, bei der aber keine Daten übermittelt werden. Hierzu muss in der Anmeldung die Mobilfunknummer +41001234567 eingegeben werden und als Firmenbezeichnung “demo”.

In den zurückgegebenen Paramtern des Verify Call wird der sogenannte “Serial” mit zurückgegeben. Sollte dieser mit “SAS” beginnen (also SASxxxxxxx), so nutzt der Kunde das PWD/OTP Verfahren. Sollte dieser mit “MID” beginnen (also MIDxxxxxx), so nutzt der Kunde das Mobile ID Verfahren. Dabei kann aber nicht zwischen Mobile ID App und Mobile ID SIM Card unterschieden werden.

Dennoch können die Ergebnisse verwendet werden, um z.B. besondere Hilfetexte (z.B. bei vergessenem Passwort etc.) dem Kunden mitzugeben, oder bestimmt auf die Bestätigung auf dem Handy zu verweisen.

Voraussetzung für die Inbetriebnahme ist eine vom Kunden unterzeichnete und von der globalen Registrierungsstelle geprüften “Konfigurations- und Annahmeerklärung”. In dieser werden die Pflichten des Betreibers einer Signaturapplikation festgehalten (z.B. die Möglichkeit der vollständigen Anzeige des zu unterzeichnenden Dokuments, Absicherung des Zugangs zum Service), aber auch die Ausprägung des Service.

Weitere Voraussetzung ist ein Zugangszertifikat, welches die Kommunikation der Signaturapplikation zum Signaturservice absichert.

Nach der Prüfung des Dokumentes erhält unser Setup Service den Auftrag zur Aufschaltung des Service mit dem zugesendeten Zugangszertifikat und der gewählten Ausprägung in der Konfigurations- und Annahmeerklärung. Bei qualifizierter Signatur wird der Service zunächst immer nur auf dem Niveau “fortgeschritten” freigeschaltet. Anschliessend wird der in der Konfigurations- und Annahmeerklärung genannte Ansprechpartner um eine Beispielsignatur mit der fortgeschrittenen Signatur gebeten. Ist diese einwandfrei, wird der Service umgeschaltet auf das Niveau “qualifiziert”, sofern dieses verlangt wurde. Hierüber wird der Kunde ebenfalls benachrichtigt. Er hat nun 10 Tage Zeit etwaige Unregelmässigkeiten direkt an das Setup Team zurückzumelden. Sollten diese in dieser Zeit nicht aufgetreten sein, ist der Anschluss an der Service abgenommen. Weitere Incidents können dann über den 1st Level Support an Swisscom gemeldet werden im Falle eines Direktvertrages mit Swisscom, andernfalls an den Reselling Partner.

Im Falle eines Siegels benötigt es neben der Konfigurations-  und Annahmeerklärung durch den Betreiber der Signaturplattform noch einen Zertifikatsantrag für das Siegelzertifikat, ein Organisationszertifikat. Im Gegensatz zum Zertifikat für die Personensignatur wird das Siegelzertifikat für drei Jahre ausgestellt. Der Zertifikatsantrag muss unterzeichnet werden von berechtigten Personen der Organisation. Die Berechtigung kann sich aus dem Register ergeben (z.B. Prokura) oder auch eine eingeschränkte Handlungsvollmacht sein, die Prokurist z.B. für die Operatoren im Rechenzentrum ausgestellt hat. Hierbei müsste Swisscom dann einen Nachweis dieser Vollmacht erhalten. Diese Personen werden vorab auch noch durch einen Vertreter der Registrierungsstelle von Swisscom persönlich mit RA-App identifiziert. Das kann z.B. auch ein RA-Agent sein, der die persönliche Identifikation vorgenommen hat. Dadurch kann die Person den Antrag mittels elektronischer Unterschrift unterzeichnen. Der Antrag wird hierzu unsigniert an Swisscom zugesendet und Swisscom lädt die Personen zur elektronischen Signatur ein. Jetzt unterscheiden sich die weiteren Schritte je nach Art des Siegels:

Fortgeschrittene Signatur: Der Antragsteller sendet Swisscom ein SSL Zertifikat zu, welches er als Zugangszertifikat für die Schnittstelle zum Siegel verwenden will.

Qualifizierte/Geregelte Signatur: Der Antragsteller vereinbart mit Swisscom einen Termin für eine gemeinsame Erstellung eines privaten Schlüssels. Dieser muss auf einem kryptographischen Device der Qualifizierung FIPS 140-2 level 2 oder ähnlich erstellt werden (z.B. Yubikey, Feitan key, Key Vault HSM Microsoft, etc.) Basierend auf diesen Schlüssel wird dann ein Zugangszertifikat erstellt. D.h. für den Signaturvorgang muss der Zugang mittels diesem Zertifikat freigegeben werden. Alternativ kann auch ein Konzept eingereicht werden, wie die Zuordnung des Zugangszertifikates zum Verantwortlichen der Organisation anderweitig erzielt werden kann.

Nein, nur PADES/CADES im Bereich von Siegeln und PADES für persönliche Signaturen.

Sie dient Swisscom als Unterstützung für die Namensfindung der ClaimedID, also des Zugangs zum Signing Service.

Sind optional immer möglich (einfach hierfür das Feld ankreuzen)

Im Moment sind wir dabei die Kapazitäten durch andere Algorithmen (Vorerzeugung von Schlüsseln) und HW Ausbau stark auszubauen. Da mehrere Kunden den Service nutzen gehen wir pro Kunde durchschnittlich von einer Maximallast von einer Anfrage pro Sekunde aus. Höhere Performance, d.h. besonders reservierte Kapazitäten sind optional möglich.

Ca. 250. Die Beschränkung ergibt sich weniger aus dem Service als aus den Security Systemen.

Bitte beachten Sie, dass wir eine WAF im Einsatz haben, um unseren Service vor Denial-of-Service Attacken zu schützen. Bitte kontaktieren Sie uns vor einem solchen Test.

Für die Signatur muss eine Willensbekundung (Authorisierung) mit Mobile ID (SIM/App) oder PWD/OTP abgegeben werden. Nach Anfrage hat der Nutzer in der Regel 80 Sekunden Zeit die Authorisierung einzugeben. Der Wert ist nicht einstellbar.

Neben einer Docusign Lizenz, muss von Docusign oder seinem Reseller das Produkt “Docusign Express SKU” erworben werden und ein Ticket für die Erstellung des Swisscom Pens (des Auswahlfeldes für die Swisscom Signatur) muss beim Docusign Support eingereicht werden. Bei Swisscom müssen Sie den Docusign Connector bestellen und einen Servicevertrag zur Signatur abschliessen.

You don’t have the correct assurance level to sign this document. Please contact the RA Agent of your company” wird als Fehlermeldung herausgegeben.

Die Gesamtprüfung im Validator zeigt die Nichtgültigkeit an, sofern eine Signatur nicht den Erfordernissen von eIDAS respektive ZertES entspricht. Da Docusign neben der QES von Swisscom ebenfalls noch ein eigenes Siegel der Firma Entrust hinzufügt, welches die Erfordernisse der Gesetzgebung nicht erfüllt wird neben der gültigen QES Signatur das Siegel moniert und führt insgesamt zu einer negativen Bewertung. Dennoch ist vor Gericht natürlich die QES gültig. Mit einem Ticket an den Docusign Support kann dieses Siegel auf Wunsch auch unterdrückt werden.

Der Docusign Validator wird selber derzeit nicht weiter gepflegt und akzeptiert keine Signaturen der Schweiz.

Bitte mit dem Docusign Support besprechen: Swisscom berechnet jeweils einen Connector pro “Docusign Customer Account ID”