Sinking Our Teeth Into SCEP

0 | January 20th, 2010 | Posted in Coding, Device Management

In my last post I provided a very high-level overview of some of the certificate related services in Windows Server 2008 R2, and said I would be digging further into the material. Looking through the archives it seems I have been able to produce at least one article pr month since I started this site and it almost looked like I wouldn’t deliver this month. Well, December and January are always busy months, but I did find some spare time to look into SCEP, (Simple Certificate Enrollment Protocol), and thought this was a good time to bring some more details.

The quick recap first; SCEP is a protocol defined by Cisco for enrolling machine certificates. SCEP is implemented in Windows Server as Network Device Enrollment Service (NDES). iPhone uses SCEP for secure bootstrapping/provisioning, and maybe it could be relevant for other devices too.

As far as installation of the NDES role I would recommend the following white paper by MSFT:
http://www.microsoft.com/downloads/details.aspx?familyid=E11780DE-819F-40D7-8B8E-10845BC8D446&displaylang=en

Let’s get down to actually using it. SCEP is implemented as a dll file called mscep.dll which you can interact with through HTTP GET commands. There are a couple of different operations you can specify as the desired action. The first one is called “GetCACaps” which is used to retrieve what operations and behavior the server supports, but this operation is optional and as far as I can tell it is not implemented by Microsoft.

The next, which is supported, and not optional, is “GetCACert”. An example URL of this would be:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(You’ll notice I’ve attached a message parameter as well, but the message part of the URL can be any random text at this point.)

If doing this in a browser you’ll see a response in the form of a file called “mscep”. Save this as a p7b file, and you will have the entire certificate chain of the CA relating to NDES. If you have a single Root CA, and do a “next-next” install of the NDES role you will have three certificates in the chain; one for the Root CA, and two for the certificate request agents. image

Before moving on to the next step, let’s take a quick de-tour looking at how this setup works on a high level:
You have three URLs that work in your browser
http://CA/certsrv/mscep & http://CA/certsrv/mscep/mscep.dll which will both give you the same html output:
image

http://CA/certsrv/mscep_admin which gives some info for the admin who enrolls the device:
image

And following this these are the steps involved in an enrollment:
- Device generates a key pair (public and private).
- Admin logs on to the admin page in his browser, and retrieves the password.
- Device generates a certificate signing request (CSR), and sends off to the SCEP/NDES server.
- NDES sends the request to the CA. (This can be on the same server.)
- A response is received by the device containing the actual certificate.

It does sound easy doesn’t it. You generate a request, and if you have it in the form of a file it will be a long Base64-string like this (I left out most lines of the string to make the screenshot smaller):
image

And you submit it to the NDES service through the browser:
http://CA/certsrv/mscep/mscep.dll?operation=PKIMessage&Message=MIID9Q=
I’ve left out most of the string here too, but it’s really just copy & paste everything from the CSR file except the first and last lines. You’ll once again get a file called “mscep” back, but it’s not going to work saving it as pfx, cer, etc.

Checking out the Event Viewer on the CA we see something similar to this:
image

Ah, but thing is, when I said generate a CSR above I left out a couple of the finer details. You see, you’re not able to just go through the certificate request process in IIS or the Certificates MMC. As the error indicates you aren’t getting all the details embedded that you need for a SCEP request. I found a neat tool called “ASN.1 Editor” (ASN is the format for CSR files), and thought I would be able to handcraft the request with this utility. Then it occurred to me that generating a valid key pair in my head, using it for signing, and inputting it in the request probably is well above my mental capabilities :) Nonetheless it is a useful utility if you’re generating CSRs and want to “debug” these. (If you have a certificate you already have on file, you can look at that too.)
Hit the link for download: http://lipingshare.com/Asn1Editor

This leaves us to the programmatic approach, and I’d love to have given you all some finished C# code as the next step. I ran into a couple of challenges while testing this though – the first being that support for crypto stuff is so-so in C#, barely present in Compact Framework, and dependent on the OS on the desktop side. Realistically you need to run it on Windows Server 2008/Vista or Windows 7. While I certainly have access to those platforms, and it is workable with some dll imports, it gave me a couple of pointers to where this had to be taken for building a proper solution, but not the solution itself. I initially thought that a client on Windows Mobile was feasible, but maybe it’s more work than it’s worth. You’d also have to go through all the same obstacles implementing it for the Android if that became a feature request, and you’d still have to adapt in some way if using it on the iPhone. (The iPhone already has native support courtesy of Apple Inc. mind you – I’ll get back to that.)

I’ll also admit that learning the crypto APIs required for this was more than I could chew through in an hour. I’ve managed to create a CSR programmatically and getting the same error as above, and I’ve managed to put together a request that crashes the program entirely when running. Basically I have to learn it proper if I want to get it working, and that’s probably an exercise better left for later on when I see a greater need for it. At the moment it’s more of a nice-to-have than need-to-have for what I do. (Man, I felt stupid trying to guess my way to something that would work.)

If you want the “algorithm” it works roughly like this:
Create a PKCS#10 request, wrap it in a PKCS#7 request with a couple of extra attributes (senderNonce, TransactionID, MessageType). Sign this with the public key from the certificate of the RA and submit.

If you want the gory details there’s no way to avoid reading the RFC:
http://tools.ietf.org/html/draft-nourse-scep-20
And this paper is also of great help:
http://www.gamingstandards.com/…/appendix_d_scep_operations.htm

So, let’s say for the sake of discussion that we have solved the coding issues – what would we do next? I’d probably start by removing one more obstacle on the server side. The default install of the NDES role on the CA will require you to use one-time passwords (remember the admin web page?). While this is a good secure by default implementation I find it slightly impractical  for our purposes, so let’s disable it. Navigate to regedit on your CA, and flip the following registry key to 0 (if it doesn’t exist create a DWORD value):
HKLM\Software\Microsoft\Cryptography\MSCEP\EnforcePassword\EnforcePassword

So, the iPhone works you say…How did I solve that since I didn’t see the coding through to the bitter end? Well, I resorted to “cheating” actually :) I installed the latest Feature Pack for an Afaria Server I’ve got running, since this adds iPhone support. The funny thing is that the technical approach I was evaluating was/is very similar to what Sybase have done. I’m not going into the details of the Sybase implementation as some elements are only relevant for the iPhone, and not SCEP enrollment in general, but it basically starts with an SMS sent to the device to trigger the enrollment process. The device generates a request, sends this to a provisioning server, and the server signs this request before passing it onto the CA. The iPhone picks up the generated certificate by talking to the CA directly though, and doesn’t do everything through the provisioning server. (I’m not entirely sure as to when the communication end-points are switched.)

What I’m thinking is that it should be possible to channel everything through a proxy web service so you don’t have to expose the CA directly to the Internet. (Yes, I am aware of a reverse proxy like ISA Server, but not published at all is even better.) This web service could also handle requests from both clients able to generate the actual request themselves, and clients who has to make do with a “light” request and have the server do the rest.

Eventually you should end up with a certificate on your device, and your CA will have it on record if you get it right:
image
Notice how the common name does not easily identify the device.

So, great, another certificate on the device. What to do with it? The iPhone uses it for signing of the provisioning profiles you send to it. You can lock down the iPhone with security policies – like enforcing Power-on-Password, removing YouTube/Camera/AppStore, and the user will not be able to remove it.

While I haven’t investigated it further I believe it should be possible to enforce restrictions like only allowing devices with the proper device certificate to access ActiveSync – while still allowing ActiveSync without the need for VPN tunnels and the like. Like so many other things – the technology is there and it’s up to you to find a use for it :)

Certificates – A Minor Technology Update

0 | December 3rd, 2009 | Posted in Coding, Device Management, Mobility Rant

A couple of weeks ago I performed an upgrade of my LAN at home. A trusty old Pentium 4 that had been doing it’s duties as a Windows Server 2003 domain controller showed signs of old age, and kept locking up at an increasing rate. I’m guessing that the hard drives, and possibly a couple of the fans had started to take enough of the abuse :) Trying to fix it wouldn’t make sense economically, and while I’ve spare parts and computers with similar specs I wanted to go 64-bit. It all ended up in me re-installing two low-end PowerEdge tower servers running Windows Server 2008 to 2008 R2. The improvements in Hyper-V was one of the reasons, but while at it I thought it would be a good idea to upgrade the domain controller too. (Note to others out there running Linux-based NAS boxes: don’t assume they like 2008 DCs just because they boast AD integration, and worked happily with 2003. Samba can bite my shiny metal ass…)

I haven’t actually upgraded the forest and domain level to 2008 yet, as most services will run with 2003 levels. I haven’t gone the whole nine yards transitioning to IPv6 either for that matter. What I have been taking a closer look at is Certificate Services. It’s been one of those components that have just been working for a long time out of the box, but the feature list said there were a couple of new bits to take note of. I’d like to provide a minor update based on a few things I have learned so far about them :)

Network Device Enrollment Service
The first “new” feature is NDES. (I say “new” because it was available previously as an add-on, but now it’s a native component of the OS.) NDES stands for Network Device Enrollment Service, also known as MSCEP, which is the Microsoft implementation of Cisco’s Simple Certificate Enrollment Protocol. The purpose of SCEP is to be able to enroll certificates to Cisco equipment like routers and switches, but it is open for others to implement too. A common feature of network equipment is that you cannot always enroll certificates the same way you do with a desktop or server – often the component cannot access the CA directly through a graphical user interface, and since you don’t like moving private keys around you don’t want to be copying pfx files around either you need a different enrollment mechanism. So basically, you “assist” the device by creating a sort of pre-enrollment request, and let the rest work itself out automagically. (Of course this is over-simplifying, but hopefully you understand what I’m getting at.)

How nice, but why are you telling us this? Do we care about Cisco in this context? No, possibly not, but we do care about the iPhone. And while it’s still a love/hate thing for many IT people the iPhone is unavoidable in more and more enterprises. As much Steve Jobs possibly classifies as a megalomaniac, the man understands that to progress further with this device in the enterprise, Apple needs to add enterprise features. The 3GS sports encryption, and the latest incarnation of the OS also supports client certificate based ActiveSync and all sorts of things. And even better, they’re taking steps towards manageability providing options for bootstrapping devices through the iPhone Configuration Utility. For a single-user scenario this tool works nicely, but you don’t want to use this en masse for deploying a large number of devices. And you don’t have too – you can create xml that can be send over-the-air much like OMA DM on Nokia devices. Based on this Good Technology has support for the iPhone in their product, and Afaria from Sybase hopefully has support coming during December if there isn’t an unexpected showstopper.

The profile can be pushed as mandatory, so the user cannot uninstall it. To accomplish this the profile is signed/encrypted with a certificate, and – you guessed it. This certificate is enrolled via SCEP. Unfortunately I do not have any slick screenshots at the moment showing how this works, but do have a look at the docs from Apple to learn more:
http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

SCEP is implemented as an ISAPI plug-in in IIS, and you interface with it through HTTP POST/GET. If you want to test that it’s all working enter the following URL in your browser:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(The message part of the URL can be any random text at this point.)
You’ll be rewarded with a file called “mscep” that contains the certificate of the CA in a binary form.

To actually enroll for a certificate you need to prepare a request device side, and depending on the configuration you might need to acquire a one-time-password as well. I’m testing out how this works in a Windows Mobile context, (I don’t develop for the iPhone), so I haven’t worked out all the low level bits yet. Hoping to present something at a later time.

Certificate Enrollment Web Services
The other new feature in 2008 R2, that actually is new and not re-cycled, is Certificate Enrollment Web Services. While there’s been a web interface for enrolling certificates it has required ActiveX, needed the site to be trusted, notoriously difficult using programmatically, not really supporting mobile devices…well… a few shortcomings. But everybody loves Web Services, and it has been created to simplify enrollment from non domain-joined computers and other platforms than Windows/Internet Explorer.

While my own DojoCert utility does what it’s supposed to do there are things I’d like to see better implemented. Problem is I’ve been limited as to what I can do in C# and the .Net Compact Framework. The native C++ APIs could probably produce something, but these are also intended for enrolling via LAN/WLAN. I’m not going into all the technical details here and now, as my early experiments shows you need to perform some tweaking to use it on mobile devices. (Not there quite yet, unfortunately.)

How does it work then?
Do yourself a favor if you are interested in this topic – read the following white paper from Microsoft. Should help you out in installing it on your CA.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=28b910f8-6374-48dd-a897-11fff62ab795

The short version is – the client will ask the Enrollment Policy Web Service what templates are available, and what requirements these templates have. Based on this the client generates a certificate request, sends it off to the Enrollment Web Service, and a response is returned. Sounds ever so simple, I know, and provided I can get it working I believe it adds value as opposed to the simpler NDES scenario. (How simple it really is I do not know the extent of yet.)

NDES/SCEP are primarily intended for machine certificates, so in a scenario where you issue certificates to both devices and users you might decide to go for both, or just the web services.

I’m hard at work looking at both these two alternatives, and I hope to get something to work. Although you never know what kind of snags you run into. Will be posting more, if I find something worthwhile :)

Lazy Dialing Made Accessible

0 | December 2nd, 2009 | Posted in Coding, How-to's, Utilities

Have you ever been ever so slightly lazy when it comes to making phone calls? No, I don’t mean procrastinating when it comes to making calls you for some reason don’t feel like you’re in a hurry to do. But the kind of laziness where you feel it’s a hassle to pick up the phone to send an sms, and end up doing it on your desktop instead. I have a plug-in in Outlook that will let me send sms, or I could do it via something built upon Kannel, etc, so that’s sorted though. I decided to have a look at something similar for making calls from the desktop.

Now, I am aware of a product called Office Communications Server, and vendors like Cisco with their software. That’s besides the point for now though :) Just like food, it tastes better when it’s home made. (Or rather you learn more making your own pizza than having it delivered.)

While browsing the Compact Framework API for something completely different I stumbled across easily accessible methods that will allow me to make calls programmatically. It’s really no effort as you can see from the few lines of code below.

image

In this case I’ve created a small console application (no graphical interface) that dials the number “1234”, but I could use a number supplied as an argument too for that matter.

Hey, this is nice for spying purposes! Well, no. It’s not placed as a “secret” call in the background. The user will notice that the device makes a call, or notice after the call has been made if it was in his pocket at the time.
image

It’s not a feature complete program at the moment. We’re missing a delivery system – I mean, we can’t have a program on the device without there being some desktop/server side mechanism of triggering the client. If you have an MDM solution that let you do push of management commands it could work. Or you could send an sms from the server, intercept the message, and trigger it. You could expand the client to listen to some server, and do something a bit like ActiveSync.

But isn’t this a light overkill when you could just pick up the phone and use the keypad directly? Well, the best thing after sliced bread it certainly is not, but it could make things more user friendly in some scenarios. Take for instance a phone list on the intranet – look up the number, hit “dial” and you’re off. Or if you’re sitting in front of the desktop most of the time, wearing a headset, and making calls while the device is somewhere else on the desk. (No function to hang up here though, so maybe you should still keep the device nearby.)

Anyways, some times I just come up with crazy ideas, and leave it for others to decide if it’s worth pursuing further :) I haven’t attached a download of the program above, but if someone is interested I could probably do a proper compile and upload.

Ah, but how to test the program, passing parameters without a command line? (I cheated and ran it through Visual Studio.) I’m sure some of you are already familiar with Rapi Tools – the rest of you download them, and add them to your toolbox:
http://www.xs4all.nl/~itsme/projects/xda/tools.html

Very convenient. Use prun.exe with the app executable and parameters on your desktop, and the device executes. (You need to cradle with ActiveSync so it really only serves a practical purpose in testing scenarios.)
image 

So I’ll talk to you later then :) (Ah, the hilarious puns one come up with late at night…)