Teknik

I princip ja. Vid användning av efternamnet och förnamnet måste det vara exakt detsamma som det finns i ID eller pass. Men om det är svårt att implementera kan mallfunktionen stödja ( https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Distinguished-Name:-Use-of-Evidence-Attributes ). Denna funktion gör det möjligt att ta över exakt för- och efternamn som användes under identifiering i kombination med RA-Service (SRS).

Swisscom kan också konfigurera tjänsten så att endast en pseudonym används istället för efternamnet och förnamnet. Dessutom kan "Common Name" (CN) användas med de namn som vanligtvis används för denna person (oberoende av ID-dokumentet). RA-Service-verifieringssamtalet verifierar i det här fallet mobilnumret som användes under identifieringen och landet. Användningen av pseudonymen i verifiera samtalet är oberoende av användningen av pseudonymen i samtalsbegäran.

Ja, det finns flera bibliotek tillgängliga på marknaden som möjliggör en snabb implementering av en signaturapplikation. Alla har även specialstöd för Swisscom Service:

• Intarsys, Tyskland : tillhandahåller olika lösningar för att hantera och integrera signaturer: https://www.intarsys.de/produkte/fernsignature

Intarsys är en premiumpartner till Swisscom och kan AIS-tjänsten mycket väl ur teknisk synvinkel och kan ge konsultstöd.

• PDF-Tools, Schweiz : 3-Heights PDF Suite. http://www.pdf-tools.com/pdf20/de/produkte/pdf-security-signature/pdf-security/
• iText, Belgien : iTextPDF. https://itextpdf.com/de/products/product-tour . Swisscom använder iText i sina exempel, men exemplen är "inaktuella", dvs vissa funktioner har ändrats. Men den grundläggande hanteringen kan ses där: https://github.com/SCS-CBU-CED-IAM/itext-ais
• Setasign, Tyskland : Vissa kunder använder SetaPDF, som också erbjuder en speciell lösning för Swisscom Service: https://www.setasign.com/products/setapdf-signer/demos/swisscom-all-in-signing-service/
• Blocksigner, Schweiz (Skribble.com): https://api.skribble.com/swagger-ui.html

Swisscom frånsäger sig allt ansvar för felfri drift av dessa bibliotek. Dessa kan innehålla fel och kräver speciell kunskap och expertis. Användning sker på abonnentens egen risk.

Se https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4

Det finns ett test- och demo-läge som låter dig testa appen, men ingen data överförs. För detta ändamål måste mobiltelefonnummer +41001234567 anges i registreringsformuläret och företagsnamnet ”demo”.

Nej. Swisscom kräver till och med att när PWD / OTP-skärmen är integrerad som en “iFrame”, kan en extern person kontrollera att den härrör från Swisscom. Till exempel kan standardwebbläsarfunktionerna användas som Swisscom publicerar under sin webbplatslänk i enlighet med kapitel 4 i användarvillkoren. För integrering av iFrame, se https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Det finns inget stöd för skärmskrotning som gränssnitt. Developers kan konfronteras med det faktum att skärmarna kommer att ändras. Det är också motstridigt med implementeringen av ”ensam kontroll” mellan undertecknaren och signeringsintyget.

Ja, men bara som iFrame hittar du instruktioner här: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Nej, se https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide.

Ja, som beskrivs i referenshandboken ( www.swisscom.com/signing-service ) under "Step-Up-metod" i "Meddelande" -fältet, textblocket med rubriken till meddelandet för uttryck för avsikt och språk inställning med ”Språk” kan konfigureras inom ramen för protokollet. För SMS-inmatningsfönstret kan språket också ställas in med parametern “Språk”.

Förutsättningen för installation är en ”deklaration om konfiguration och acceptans” undertecknad av kunden och verifierad av den globala registreringsmyndigheten. Denna deklaration innehåller skyldigheterna för operatören av en signaturapplikation (t.ex. möjligheten att visa hela dokumentet som ska undertecknas, säkerställa åtkomst till tjänsten), men också tjänstens egenskaper.

En annan förutsättning är ett åtkomstcertifikat som säkrar kommunikationen av signaturapplikationen till signaturtjänsten.

Efter att ha kontrollerat dokumentet får vår inställningstjänst order att aktivera tjänsten med åtkomstcertifikatet skickat och den valda specifikationen i konfigurations- och godkännandedeklarationen. Vid kvalificerade signaturer aktiveras tjänsten initialt endast för “avancerade” signaturer. Därefter frågas den kontakt som nämns i konfigurations- och godkännandedeklarationen om en exempel signatur med den avancerade signaturen. Om detta är felfritt byts tjänsten till "kvalificerad" nivå om så krävs. Kunden kommer också att underrättas om detta. Han har nu tio dagar på sig att rapportera eventuella oegentligheter direkt till installationsteamet. Om de inte får några klagomål under denna tid accepteras anslutningen till tjänsten. Ytterligare incidenter kan sedan rapporteras till Swisscom via support på första nivån i händelse av en direkt kontakt med Swisscom eller till återförsäljarpartnern.

Åtkomstcertifikatet kan vara ett självsignerat certifikat. Till exempel med openssl programvara.

Krav för distinguished Name:

• CN=<URL för abonnentsystemet som utför kommunikationen med AIS eller annan unik identifiering av abonnentsystemet>
• O=<Organisationens namn>
• E-post=<E-post för aviseringsändamål, t.ex. vid slutet av giltigheten>
• C=<Organisationsland>

Följande ytterligare krav ska beaktas när certifikatet utarbetas:

• Maximal löptid 3 år
• Hashalgoritm minimum SHA-256
• Nyckellängd minst 3072 bitar

Särskilda villkor gäller fortfarande för åtkomstcertifikat inom ramen för reglerad (ZertES) eller kvalificerad (eIDAS) sigillskapande: Den privata nyckeln till åtkomstcertifikatet måste skapas på en kryptografisk modul i en gemensam ceremoni av en Swisscoms registreringsmyndighetsrepresentant. Denna modul måste uppfylla kraven för FIPS 140-2 nivå 2 eller liknande, t.ex. Yubikey, Feitan-nyckel eller Microsoft Key Vault. Alternativt kan ett koncept lämnas om hur tilldelningen av tillträdesbeviset till den organisationsansvarige kan åstadkommas på annat sätt.

I fallet med en försegling, förutom konfigurations- och godkännandedeklarationen från operatören av signaturplattformen, kräver det också en certifikatansökan för förseglingscertifikatet, ett organisationscertifikat. Till skillnad från intyget för den personliga signaturen utfärdas förseglingsintyget i tre år. Certifikatansökan måste undertecknas av behöriga personer i organisationen. Auktoriseringen kan härröra från registret (t.ex. upphandling) eller kan också vara en särskild fullmakt som har utfärdats till exempel för operatörerna i datacentret. Swisscom behöver bevis på denna fullmakt. Dessa personer identifieras också personligen i förväg av en representant för Swisscoms registreringskontor med RA-App. Detta kan till exempel vara en RA-agent för en återförsäljare som har utfört personlig identifiering. Detta gör det möjligt för personen att underteckna ansökan med en elektronisk signatur. Ansökan skickas till Swisscom osignerad och Swisscom inbjuder personerna att underteckna elektroniskt. Nästa steg skiljer sig nu beroende på typ av tätning:

Avancerad signatur: Sökanden skickar Swisscom ett SSL-certifikat som han vill använda som ett åtkomstcertifikat för gränssnittet till förseglingen.

Kvalificerad / reglerad signatur: Sökanden godkänner ett datum med Swisscom för gemensam skapande av en privat nyckel. Detta måste skapas på en kryptografisk enhet baserad på FIPS 140-2 nivå 2-kvalifikation eller liknande (t.ex. Yubikey, Feitan Key, Key Vault HSM Microsoft, etc.) Ett åtkomstcertifikat skapas sedan baserat på denna nyckel. Dvs för signaturprocessen måste åtkomsten frigöras med hjälp av detta certifikat. Alternativt kan ett koncept lämnas in om hur tilldelningen av åtkomstcertifikatet till den person som ansvarar för organisationen kan uppnås på andra sätt.

Inbäddning av signerade haschar bör vara uppgiften för PDF-specialister eller motsvarande bibliotek. Utrymmet för signaturen måste räknas om i förväg. Ta en titt på https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4 .

Följande lösning kan ge en lösning. Vi presenterar detta här utan garanti, eftersom Swisscom bara fokuserar på tjänsten och inte på signaturansökan:

• Skapa en PDF med ett tomt och förfylld signaturfält
• Byteområdet bör fyllas med nollor upp till den förväntade storleken
• Beräkna dokumentets hash
• Signera hashen med All-in Signing Service
• Fyll den signerade hash i det tomma signaturfältet
• Iterera till det tomma signaturfältet
• Bestäm byteområdet för det tomma signaturfältet
• Beräkna offset för byteområdet
• Öppna dokumentet med det tomma signaturfältet i läs-skrivläge och hitta den förskjutning där hashen sattes in

Det är också mycket viktigt att följa riktlinjerna för PADES-standarden och Long Term Validation: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation

I de returnerade parametrarna för Verifiera samtalet returneras den så kallade "serien". Om detta börjar med “SAS” (dvs. SASxxxxxxx) kommer kunden att använda PWD / OTP-autentisering. Om detta börjar med “MID” (dvs. MIDxxxxxx) använder kunden proceduren Mobile ID. Det är dock inte möjligt att skilja mellan Mobile ID App och Mobile ID SIM-kort.

Resultaten kan ändå användas, t.ex. för att tillhandahålla specialhjälpstexter (t.ex. om lösenordet glömts etc.) till kunden, eller för att hänvisa till viljedeklarationen på mobiltelefonen.

VerifierCall låter dig kontrollera om en undertecknare redan är registrerad eller inte. Om du väljer pseudonym behöver du bara undertecknarens mobilnummer och land. https://documents.swisscom.com/product/filestore/lib/4cce2074-46e3-4e43-a1b4-ccf5d5cb7ca5/VerifyID4Signing-de.pdf

PKCS#1 stöds endast för CADES -format och tätningar men inte för personliga signaturer.

Nej, bara PADES/CADES för tätningar och PADES för personliga signaturer.

Det stöder Swisscom att hitta ett namn för ClaimedID (åtkomst till signing service).

Ja, kryssa i lämplig kryssruta.

Just nu håller vi på att utöka vår kapacitet med andra algoritmer (förgenerering av nycklar) och HW-expansion. Eftersom flera kunder använder tjänsten antar vi en maximal belastning på en begäran per sekund i genomsnitt per kund. Högre prestanda, dvs speciellt reserverad kapacitet är valfritt möjlig.

Det är begränsat till 250 på grund av säkerhetsskäl snarare än på tjänstens kapacitet.

Tänk på att vi installerade en WAF för att skydda vår tjänst igen denial-of-service attacker. Kontakta oss i förväg om du vill genomföra några massprov.

Signaturen måste undertecknas med en viljedeklaration (auktorisation) av Mobile ID (SIM / App) eller PWD / OTP. Efter att ha skickat begäran har användaren vanligtvis 80 sekunder på sig att ange auktoriseringen. Värdet är inte justerbart.