Hasain Alshakarti

I en bunker långt under Normalms gator finns “The Nerd Herd” studion, där produceras det varje vecka tunga teknikprogram med erkända experter!

Tillsammans med Johan Persson, Michael Anderberg och Fredrik ”DXter” Jonsson försöker vi under detta avsnitt ge våra synpunkter och tankar om och kring PKI i och PKI relaterade frågor och funderingar…

Avsnittet kan laddas ner här… (Du kan även prenumerera på showen i iTunes och gPodder – ge gärna en positiv review också, så att fler kan hitta showen, tack!)

Du kan givetvis följa The Nerd Herd på http://thenerdherdse.wordpress.com, DXter på hans blogg http://poweradmin.se

/Hasain

The certificate selection user interface in Windows supports filtering logic to provide a simplified user experience when an application presents multiple certificates. But some applications are not designed to use filtering logic (developers not aware of functionality…) or uses filters that does not provide efficient reduction of the number of certificates presented to the user making it almost impossible for a user to know witch certificate to choose unless opening the certificate and looking at the details of template name, EKU, etc.

This is particularly true when all certificates has been automatically enrolled using the same user DN/CN attribute based on the users Active Directory user object attributes. In addition to that, Autoenrollment does not support variations in certificate subject name unless using some third party policy module installed on the Active Directory Certificates Services.

Knowing that the certificate selection UI supports certificate friendly names. Setting the certificate friendly name to include information about the certificate template can simplify the users task to select the correct certificate.

Friendly names are properties in the X.509 certificate store in Windows that can be set at any time after the certificate has been created/installed in the store.

One way to set the friendly name is through the certificate MMC SnapIn. Alternatively certutil.exe can be used in the following way:

Create a text file containing the following information:

[Version]
Signature = “$Windows NT$”
[Properties]
11 = “{text}My Friendly Name”

Save the file as friendlyname.inf

Determine the serialnumber of the certificate where the friendly name should be changed.

Run the following command at a command-line:
certutil –repairstore –user my {SerialNumber} FriendlyName.inf

Automating the friendly name can be achieved by either automating/scripting the steps above alternatively by creating a tool that enumerates all certificates in the personal store and assign the friendly name.

A proof of concept CertFN.exe tool was created to automate the above. The tool receives a parameter for the template name to use when filtering the user store, it then sets the friendly name based on the schema “Template Name – Certificate Subject Name”

  CertFN - Certificate Friendly Name Tool download:(39.3 KiB, 4,381)

  CertFN - Certificate Friendly Name Tool - The Powershell Edition download:(1.1 KiB, 5,615)

The Basics of PKI

Public Key Infrastructure (PKI) refers to the set of hardware, software, people, policies, and procedures necessary to create, manage, store, distribute, and revoke certificates based on public key cryptography. The characteristic operation of PKI is known as certification (the issuance of certificates). PKI certification provides a framework for the security feature known as authentication (proof of identification).

Understanding the role of PKI in identity management involves the following basic terms:

• The Public/Private Key Pair – The mathematics of public/private key pairs is beyond the scope of this guide, but it is important to note the functional relationship between a public and a private key. PKI cryptographic algorithms use the public key of the receiver of an encrypted message to encrypt data, and the related private key and only the related private key to decrypt the encrypted message.
• Digital Signature – A digital signature of a message is created with the signer’s private key. The corresponding public key, which is available to everyone, is then used to verify this signature. The secrecy of the private key must be maintained because the framework falls apart after the private key is compromised.
• Certification Authority (CA) – An authority that trusted to create and issue certificates that contain public keys acting as a trust in a public key infrastructure and providing services that authenticate the identity of individuals, computers, and other entities in a network.
• Certificate – A data structure containing an entities public key and related identification information, which is digitally signed with the private key of the CA that issued it. The certificate securely binds together the information that it contains; any attempt to tamper with it will be detected at the time of use.
• Self-signed – In a self-signed certificate, the public key in the certificate and the key used to verify the certificate are the same. Some self-signed certificates are designated as Root CAs.
• Root CA – A root CA is a special class of CA, which is trusted unconditionally by a client and is at the top of a certification hierarchy. All certificate chains terminate at a root CA. The root authority must sign its own certificate because there is no higher certifying authority in the certification hierarchy.
• Subordinate CA / Intermediate CA / Cross CA / Bridge CA – A CA that has been certified by another CA. Subordination creates a managed trust between separate certification authorities resulting in CA hierarchies.
• Certificate policy and practice statements –  The two documents that outline how the CA and its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the trust is broken, and so on.
• Public key standards – Standards are developed to describe the syntax for digital signing and encrypting of messages and to ensure that a user has an appropriate private key. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, as specified in RFC5280 is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for the Internet.
• Revocation and Expiration – Certificates are issued with a planned lifetime, which is defined through a validity start time and an explicit expiration date. Once issued, a certificate becomes valid when its validity time has been reached, and it is considered valid until its expiration date. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA, and compromise or suspected compromise of the corresponding private key. Under such circumstances, the issuing CA needs to revoke the certificate.
• Registration Authority (RA) – A Registration Authority vouches to a CA for the binding between public keys and the identity and attributes of a prospective certificate holder. Essentially, using the RA is a form of administrative delegation—the CA delegates to the RA the task of verifying the binding of a public key to an entity.
• Certificate Chains – A certificate chain consists of all the certificates needed to certify the subject identified by the end certificate. In practice this includes the end certificate, the certificates of intermediate CAs, and the certificate of a root CA trusted by all parties in the chain. Every intermediate CA in the chain holds a certificate issued by the CA one level above it in the trust hierarchy.

Internet Explorer 7 and later. In order to confirm the identity of organizations that host secure webpages, certifying authorities issue security certificates. These certificates are validated when you request a secure webpage.

By default, Internet Explorer performs a number of steps in order to validate the security certificate for a secure website. If a certificate is invalid, is out-of-date, or improperly identifies the website in question, Internet Explorer displays a notification to the user.

As an additional verification step, many certifying authorities also provide a service that identifies certificates that have been recently revoked. Earlier versions of Internet Explorer displayed notifications when this service could not be reached.

Because the inability to reach these services does not necessarily indicate that a certificate has been revoked, many users complained that such notifications were “false positives.” After considerable negative feedback, these notifications were disabled by default in Internet Explorer 7 and later.

When enabled, the FEATURE_WARN_ON_SEC_CERT_REV_FAILED feature displays notifications when Internet Explorer cannot reach the certificate revocation service published by a certifying authority. By default, this feature is disabled for Internet Explorer. This feature is not supported for applications hosting the WebBrowser Control.

To enable this feature using the registry, add the name of the Internet Explorer executable file to the following setting.

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]
“iexplore.exe”=dword:00000001

The feature is enabled when the value is set to (DWORD) 00000001 and disabled when the value is (DWORD) 00000000.

Tack alla deltagare som besökte våra sessioner på TechDays i västerås, som jag lovade så bifogar jag mina anteckningar som jag gjorde under min session om PKI i denna post

Observera att filen måste döpas om till .xps

/Hasain

To import keys using the Microsoft Base Smart Card Crypto Service Provider you need to performe the following steps:

1.  Modify the registry keysbelow:
   • HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Smart Card Crypto Provider\AllowPrivateExchangeKeyImport=DWORD:0x1
   • HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Smart Card Crypto Provider\AllowPrivateSignatureKeyImport=DWORD:0x1
2.  Use the certutil.exe tool to import the key stored in a pfx file:
   •  certutil –csp "Microsoft Base Smart Card Crypto Provider" –importpfx {PFXfile}

/Hasain

This is the third time i have been asked if I consider it fine to copy an issuing CA:s keys and certificate to the new device the network department just installed for the simple reason that it needs to enroll certificates from a trusted CA, and be able to performe SSL Inspection on all outbound HTTPS traffic without causing certificate errors on the clients.

If you think about it for a while, and specially if your issuing CA is AD integrated, would not that mean that your network department can just impersonate any account in your AD? Sure you trust the network department but what about that device and the software used?

The main reason to do SSL Inspection is to be able to filter on the content of the "secure universal firewall bypassing protoocol", yes the bad guyes are using it to fool your IDS, IPS, Layer 7  Firewall etc. What do you think would happen if the SSL Inspection layer you are using hade som vulnerabilities, yes this kind of software does have vulnerabilities as well, that could be used by an attacker to extract your issuing CA keys and certificate and….

The best answer would be to create a new self signed CA certificate and trust that in your client computers for server authentication purposes such as to prove the identity of webservers. This CA should not be trusted by any of your servers and none of your DCs for som very clear reasons.

My advice to you is to be very carefull where you put your CA keys and how far you can trust the place!

/Hasain

Under den tid som minidriver-baserade smartkort har funnits så har det varit ganska jobbigt att hantera admin/user pin på dessa kort om man inte haft tillgång till produkter och ramverk så som CLM.

Jag tycker att det är en "mänskligrättighet" att kunna hantera koder på ett smartkort för den som äger kortet; med en massa tjat från mig och mycket arbete från min kollega Björn Österman så kommer det snart att finnas ett verktyg för ganska komplett hantering av admin/user pin på minidriver-baserade kort. Verktyget kommer att finnas för nedladdning från LabCenter webben www.labcenter.se, dessutom kommer den att vara Open Source.

Man kommer att kunna unblocka ett kort med tillgång till admin pin, byta pin, byta admin pin samt använda den till att skapa svaret på den utmaning man får från pintool.exe i XP och  Vista i då en användare vill unblocka sitt kort. 

scUtil.exe unblockpin  <adminkey>  <newpin>
scUtil.exe changepin  <oldpin>  <newpin>
scUtil.exe changeadminkey  <oldadminkey>  <newadminkey>
scUtil.exe calculateresponse  <key>  <challange>

Windows Vista och Windows Server 2008 har som bekant gjort det möjligt att använda certifikat för Smart Card Logon utan kraven på UPN och EKU i certifikaten. Denna möjlighet har nu kommit till Windows Server 2003, inte fullt så felxibelt som i Vista / 2008 med en bra början.

För en tid sedan så blev jag inblandad i ett projekt med fokus på smartkort, vi har sedan dess genomfört en massa olika tester av kort, läsare, csp:er och en massa kobinationer av utgivare och verktyg för att kunna hantera olika kombinationer.

Att använda sig av en extern CA för smart card logon var en av de tester som vi hade på vår lista, med utgångspunkten i KB:n på http://support.microsoft.com/kb/281245 så kunnde vi konstatera att det inte var så flexibelt som man önskade sig men efter lite sökande så hittade jag följande KB på http://support.microsoft.com/kb/936358, en patch till Windows Server 2003 som tar bort kravet på EKU! 

Efter att ha ringt supporten och fått patchen så var det tid att installera och testa den, sagt och gjort fixades en lämplig DC med CA och en Vista klient. Testerna visade dock inga av de förväntade resultaten så efter lite bollande kunnde jag konstatera att det bara var kravet på EKU som slopades och att kravet på en UPN i certifikatet fanns kvar! Det blev inte riktigt vågen men nästan, en bra början som sagt….

Vill du se detta live och eller diskutera det så kommer jag att visa det under Windows Server 2008 Summiten den 5:e december, vi ses där 🙂

/Hasain

Så reagerade kunden när jag var färdig med min insats hos de idag!

Det hela började förra veckan då en av mina kunder ringer och frågar varför det går så segt med att köra smart card logon i en Windows XP SP2. Jag har ju gjort detta på annat håll och där var det blixt snabbt, det måste vara något med vår PKI, sa kunden.

Jag hälpte en anna kund för inte så länge sedan att utvärdera olika smartkorttillsammans med ett antal olika CSP:er och smartkortläsare, resultatet blev ganska talande när .net korten var de absolut snabbaste och detta var oavsett vilket läsare man använt, skillnade var upp till ca 50 sec i värsta fall. I procent mätt så pendlade skillnaden mellan 30% och x100% snabbare hantering om kortet som satt i var .net.

Innan du skaffar smartkort för test kolla om du inte kan klara dig med .net korten, de är båda enklare och snabbare att ha i ett Windows baserat system!

/Hasain

Jag skriver detta efter att ha gått igenom alla mina appar som jag hade på min maskin innan uppgraderingen och kan konstatera att det fortfarande funkar bra 🙂

Jag vet att många tycker att man ska passa på att installera om när en ny version kommer och jag tror jag behöver göra det snart men just nu får det gå med en uppgradering till 7.10 när jag är i mitten av en leverans period och alla mina saker måste funkgera smärtfritt efter helgen.

Har dessutom gjort livet surt för en del hackers som har hållit på o terroriserat en nära vän som bedriver ett forum där åsikterna inte stämmer överens med de hos hackergruppen i frågan, det är kul att ge tillbaka utan att bryta mot några lagar och se hur frustrerade de har blivit.

Jag har fått ett par .net 2+ smartkort med dena nya minidrivern och ska försöka testa dessa under tiden som kommer, det som är mest spännande med de är P11 gränssnittet som borde innebära att korten är mer kompatibla med Uni-kryss. Återkommer med mer information när jag hunnit testa lite.

/Hasain 

När man installerar en SBS server så får man med ett self-signed certifikat med flera CN i subject-fältet, detta är ganska praktiskt om man har en server som man vill nå med https och olika namn utan den berömda certifikat varningen.

Om du själv vill skapa ett sådant certifikat med hjälp av din Windows 2003 baserade CA så kan du göra det genom att följa denna instruktion:

1. Tala om för CA tjänsten att det är OK att ändra Subject och Alternative Subject Name i ett cert request genom att köra följande kommandon på din CA server:
1. certutil.exe -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
2. certutil.exe -setreg ca\CRLFlags +CRLF_ALLOW_REQUEST_ATTRIBUTE_SUBJECT
2. Starta om Certsvc tjänsten så att inställningarna tas i bruk
3. Skapa ett certifikat begärna (cert request), eller använd exempelvis den som kommer från IIS:ens certifikat guide
• Om du vill skapa en egen request  baserad på en bef. mall så kan du använda följande steg
1. Spara ner filen req.txt (kolla attachements) till din lokala disk
2. ändra i den så CertificateTemplate pekar på den mall du vill utgå ifrån
3. kör:  certreq.exe -new req.txt cert-req.txt
4. kör följande kommando för att ändra subject-fältet så att den innehåller flera CN=
• certreq.exe -attrib "CN:localhost\nCN:www.test.com" -submit cert-req.txt new.cer
5. Installera certifikatet och koppla den till det nyckelpar som skapats genom att köra: certreq.exe -accept new.cer
6. Kör certmgr.msc och titta under private så hittar du det nya certifikatet och kan exportera den tillsammans med nycklarna

/Hasain

PKI finns idag i de flesta tillämpningar som körs under Linux, om stödet inte finns med från början så går det i de flesta gångerna att lägga till det i efter hand och är man lite händig själv så kan man fixa till PKI i det mesta men då får man vara beredd att sätta sig vid tangentbordet själv 🙂

Efter att ha konstaterat att PKI är ganska supporterad i Ubuntu/Linux, så kom turen till att testa med smartkort. För att smartkort ska funka så behövs en drivrutin till läsaren och CSP programvara som mappar mellan rådande standard och smartkortet. De standard som används i Linux när det gäller smartkort är PKCS11 och korten är antigen PKCS15 eller så emuleras PKCS15 av CSP.

Det finns två projekt som kommit längst i Linux när det gäller smartkort, OpenSC som kan hantera många kort med filsystem och RSA modul är den ena och Musclecard so kan hantera många java-baserade kort är den andra. Jag började med att testa OpenSC och har mer eller mindre fastnat för den 😉

OpenSC klarar av att prata med smartkort och läsare baserade på CT-API, PC/SC och OpenCT. läsaren som jag använder är Gemplus GemPC Twin som är ett USB CCID och kommunicerar med PC/SC. det som behövdes för att få fat på läsaren är libccid(driver för CCID USB Readers), Pcscd(PC/SC Middleware) och OpenSC(PKCS11/15 tools and API) med tillhörande plugins för exempelvis Mozilla.

Om man ska jämföra lite så måste jag säga att jag saknar den kompletta CSP implementationen som ju finns i Windows! I Linux så stödjer alla ett gränssnitt mot PKCS11 men den finns inte i själva OS:et eller på ett automatiserat sätt utan måste pluggas in i varje applikation eller de lav systemet på ett mer eller mindre mauellt sätt. Den manuella aktiviteten är nödvändig i början och allt brukar funka om man byter kort eller läsare givet att det nya kortet och den nya läsaren är kompatibla med systemet.

Jag har testat och kört Smartkort i Firefox samt lokal smartkortlogon i Ubuntu. För Firefox så behöver man manuellt lägga till en modul för att kunna använda smartkortet via OpenSC, efter det så finns kortet och de cert och nycklar för HTTPS/SSL inloggning. Lokalinloggnig med smartkort i Ubuntu var lite mer av ett äventyr, det fanns färdiga PAM moduler men ingen av de funkade, man fick bara ett fel meddelande om att signeringen inte kunnde genomföras, efter lite tester så visade det sig att det meddelande som skickades till kortet för signering var för långt, det är troligtvis en miss i testprocessen där man inte räknat med begränsningar som beror på korten eller mjukvaran runt dessa. Efter en justering och en ny kompilerad pam-modul så funkade det utmärkt 🙂

Det finns två varianter av smartcardlogon som pam-modul, en som inte genomför någon kontroll av certkedjan och CRL:en och en som följer konstens alla regler och kan automatiskt mappa användare i systemet beroende på egenskaper i det cert som finns på kortet. Den första av dessa funkar fint med selfsigned certfikat och är ganska enkel att sätta upp då man lägger certfikatet i en fil i användarens hemmamapp, vid inloggning kommer pam-modulen att försöka hitta lämpliga nycklar på det kort som sitter i läsaren som matchar certet, den kommer sedan att be kortet signera lite slumpdata för att sedan verifiera signaturen mot det certo och nyckel som finns i användarens hemmamapp.

Smartkortlogon via SSH ska enligt uppgift från Johannes G. funkar bra, har själv inte hunnit testa dett men hoppas kunna återkomma om det.

/Hasain

Det finns en mängd olika guider om hur man ska bete se för att säkra en standard installation av div OS, detta är inte något sådant utan bara min egna tankar om en nyinstallation Ubuntu!

Det finns två frågor att ta ställning till:

1. Kan någon komma åt mitt system via nätverket?
   Nej, jag kommer inte att exponera några tjänster, och är det så att jag gör det så ska en brandvägg kontrollera vem kan ansluta alternativ ska detta aktiveras vid behov, rent manuellt altså 🙂
2. Kommer jag att köra godtycklig kod på min maskin?
   Kanske?! jag kommer nog att surfa lite och så vill man installera lite appar och sånt. Då är det viktigt att inte vara inloggad som root och dessutom vara försiktig vart man tar vägen och vad browsern får göra.

   Det första fixar Ubuntu lika snyggt som exempelvis UAC i Vista, det andra fixar vi med lite plugins till firefox som exempelvis noscript och adblock och så fixar vi en hosts fil som tar hand om adresser till kända bråkmakare som reklamsiter och annat smått och gått man inte vill ha kontakt med.

När den gäller säkerheten i filsystemet så SKA filsystemet vara krypterat, om du inte kan ha ett krypterat filsystem så tänk på att skydda single user logon via ett lösenord(MD5) i menu.lst och glöm inte att ställa in rättigheterna ordentligt i filsystemet, detta speciellt om det finns flera olika användare i systemet.

Hosts filer finns det gott om på nätet, prova "mvps hosts" i google, ett händigt skript för att styra brandväggen hittar du bland bifogade filer.

Nästa inlägg kommer att handla om att glömma lösenorden i Ubuntu och börja köra certfikat och PKI.

/Hasain