Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Problems and Promise in the World's Largest PKI

By imrdkl in Technology
Thu Feb 19, 2004 at 09:57:36 AM EST
Tags: Security (all tags)
Security

Implementing a Public Key Infrastructure (PKI) on any scale is a challenging, politically-charged task for an IT professional. Even though a working PKI is an important piece of a complete security package for an organization, the lack of interest, misunderstanding, laziness, and downright paranoia of the typical user population can turn a PKI effort into just another morass of documents for which the contractors have been paid and long ago moved on to some new revenue channel. Given the dismal success rate, it's difficult to imagine a successful PKI, not for hundreds or even thousands of users, but for millions. Yet, that seems to be what the Department of Defense (DoD) has accomplished in their Common Access Card (CAC) project - the new identification cards being issued to all US military personnel. To date, CAC PKI project has issued and manages more than six million digital certificates and corresponding smart cards.

As someone who has implemented a PKI for a large, diverse organization, I can say that the IT professionals who worked to make the CAC project a success are entitled to pat themselves on the back, but it's also clear that a few problems remain.


We've discussed PKI and digital certificates before on this forum (part 1, part 2, part 3), so a lengthy introduction to the concepts shouldn't be necessary. Basically, a PKI attaches identities to digital certificates for the purpose of assured, verifiable, and secure digital communications. Most PKI implementations are concerned with human identities, although some exist for the purpose of identifying machines, companies, groups, or other entities.

During the late 1990s, and faced with the security problems posed by open internet access to military information, the DoD committed to PKI for its members as a concept, and began to make plans for implementing it. Late in 2002, after several years of development, they marked the one-millionth CAC card issued, calling it a "monumental step" - but there was still a long way to go at that time, and millions of digital certificates yet to issue. Now the online edition of Military Information Technology has just published an interview with Gil Nolte, a National Security Agency (NSA) official who serves as director of the DoD PKI programs, and he gives a frank and open view of the CAC PKI efforts to date. According to Nolte, more than 80% of all active-duty military personnel now have CAC smart cards. While that's encouraging, in that six million American citizens now possess at least a rudimentary knowledge of public key cryptography and how to use it, Nolte's commentary regarding the failures and problems which have been encountered in the CAC project are somewhat disturbing. The success of the project must be weighed against the "workarounds" necessary to make it "march in step" to the demands and limitations of the US military organization.

The ActivCard was chosen by the DoD as the platform for the CAC. The latest generation of these smart cards contain multiple credentials, including unique RFID, barcode, photo ID, and biometric information (fingerprints), along with the crypto keys and certificates. A diagram of the modern CAC card shows how they work. To obtain a one, a soldier follows a relatively simplified process. The cards, and their biometric data, crypto-keys, and certificates are issued and maintained by a system known as the Defense Enrollment Eligibility Reporting System (DEERS) and the Real-time Automated Personnel Identification System (RAPIDS). To find the nearest RAPIDS enrollment center, a simple search functionality is provided on the open web. After the soldier has found a suitable enrollment location, he schedules an appointment and at the appropriate time, arrives to begin the application process. The time required for this process has been greatly reduced during the past few years - nowadays the average wait for a CAC card is only about 12 minutes, although delays are still somewhat common. Indeed, delays in the application and issuance of the CAC have been the project's largest single problem. The streamlined application process seems to have helped, but according to Nolte, "We still have issues - some sites are still reporting long issuing times."

Before we take a deeper look at the other problems faced by the CAC PKI, we should be aware of what they actually do for the military personell who receive them. Besides providing physical identification capabilities mentioned previously, the CAC contains a couple of digital certificates. A client certificate, which authenticates the soldier and grants access to 2-way SSL protected websites; and an email certificate which provides the soldier with the ability to sign their email communications, providing assurance to the receiver that he is indeed who he says he is. Additionally, email to a soldier may be encrypted when necessary and prudent using their email certificate. To send an encrypted message to a soldier, their public key is obtained through an internal database.

Leading up to the invasion of Iraq, the US military restricted e-mail from certain personnel which was being sent home to friends and family. Concerns about inadvertent leaks of battlefield information and other secrets forced the clampdown. It's unclear whether the new encryption capabilities which are available via the CAC could be used to reduce this risk, but it could reduce the potential for certain types of leaks. It's also unclear whether the military's public-key database is available to the public, or even to family members, but it's certainly possible for the soldier to carry his family's public keys with him in any case - now that the capability for sending secure email is available and understood by regular personnel

While it seems clear that the biggest stumbling block to a successful PKI in the US military has been the delay - the waiting time between sending the certreq and receiving the certificates, there were several other big problems to work out. Among these, probably the biggest and most confounding was simply trust. In the early stages of PKI within the military, there were reports that several different vendors and implementations were being used and/or developed, leading to complex and confusing cross-validation requirements. Nowadays, the one and only root PKI authority, the one which signs and approves all other military PKI authority, is managed by the National Security Agency. This subjugation was a critical step for the largest PKI in the world - although I can imagine that there were more than a few rankled generals and admirals who had to submit applications for their authority to the NSA.

Another big problem which has cropped up for the DoD's PKI is related to the enormous Certificate Revocation List (CRL) which must be maintained and updated for proper validation of each transaction which occurs using a DoD certificate. The list of revoked certificates is currently well over 21 megabytes, and searching the list for invalid certificates is currently forcing some applications to forego a comprehensive check before carrying out a given transaction. This flaw was predictable, CRL maintenance is one of the "hard" problems facing any CA, but it remains a significant security flaw in the operation of the PKI. An unverified transaction can provide important information or access to an intruder, who might even be the enemy. However, most of the application owners have accepted the risk, and continue to operate without CRL verification. They're waiting on a fix from the root authority, according to Nolte. Let's just hope that their continued development funding doesn't get sucked into Iraq.

It's also worth mentioning, when considering the problems faced by the DoD PKI, that most of the functionality which implements the PKI is MS Windows-based. Indeed, the RAPID system itself runs under Windows NT (PDF), and most, if not all secured email communication which are sent from military personnel are also sent using MS Windows software. In light of the recent ASN.1 parser critical vulnerability discovered in Windows, which could lead to exploits which give complete control of systems which make use of certificates and cryptography, it's disconcerting, but not surprising, to realize that the US military has placed all of their PKI "eggs" in one basket. Hopefully, such vulnerabilities are patched religiously, or at least methodically, by the administrators of these systems.

Finally, taking a look at the future of the DoD's PKI efforts, Nolte notes that there's a "long list" of functional capabilities for the CAC PKI which have been prioritized by the information officers representing the military. Among them, the most critical appears to be replacement of lost or damaged keys. Now, most CA operators do not provide this functionality, since most CA operators do not retain copies of the private keys. The DoD however, being an escrow CA operator, can provide the ability to restore lost or damaged private keys. The problem with doing so, of course, is validation and proper identification of the recipient, as well as proper storage and retrieval methods for the keys themselves. Anything which makes it "easy" to recover a lost key also makes it easier to obtain it illicitly - this is why most CA operators don't provide key escrow, period. Nolte relates an incident which highlights the problem, where a very high ranking officer lost his keys, and was unable to access vital data for several days during a critical time last year.

Trade-offs are a necessary part of any large organizations' security and public key infrastructure, as anyone who has worked on one knows. At some point, however, sacrificing enhanced security for the sake of simplicity makes what remains of the security a farce. It's not clear to me that the CAC is a farce yet, but continued pressure to "make it easier" could certainly reduce it to that level. I wish them continued success, but not at the cost of reliability or real security.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Do you belong to a PKI today?
o Yes 35%
o No 60%
o Not yet, but soon. 4%

Votes: 45
Results | Other Polls

Related Links
o Public Key Infrastructure
o dismal success rate
o part 1
o part 2
o part 3
o marked the one-millionth CAC card
o Military Information Technology
o interview with Gil Nolte
o ActivCard
o diagram
o simplified process
o is provided
o restricted e-mail
o sending the certreq
o runs under Windows NT
o ASN.1 parser critical vulnerability
o Also by imrdkl


Display: Sort:
Problems and Promise in the World's Largest PKI | 42 comments (32 topical, 10 editorial, 1 hidden)
Ha. Ha ha. BWAHAHAHAHA (2.78 / 14) (#4)
by curien on Wed Feb 18, 2004 at 09:58:22 AM EST

Sorry, couldn't resist. I stopped reading when you declared the DoD PKI rollout a "success" and skimmed through the rest. Here's why it's not.
  • There exists no PKI trust chain outside the root CA and a intermediate CAs used by the folks at the PKI SPOs.
  • PKI isn't integrated with our directory structure. Oh, wait, that's because we don't have a directory structure yet. At best, there are several un-related forests, which they plan to link together using a meta-directory service. Oh, that sounds like a great idea!
  • I saw you said something about CRLs, but DoD PKI hasn't implemented CRLs in any meaningful way, yet. (They can't without the above-mentioned meta-directory, and probably a meta-meta-directory.) So instead, in order to validate certs, each base downloads a (currently) 28GB file from their branch SPO with a list of valid certs.
  • The current CAC cards have only 16KB of memory, which isn't really useful for much other than storing a few certs. They want to store things like medical records, which requires replacing all existing cards.
  • There's currently no way to sign messages from an organizational mailbox. DoD PKI policy is to not issue soft certs (ie, private key in a file instead of on a SC) which would allow us to do this. Hint: all important e-mail traffic comes from organizational boxes.
  • My CAC card has my current e-mail address hard-coded into it. My e-mail has my base name. When I PCS in a few months, I'll have to get new certs. When I get new certs, I'll no longer be able to decrypt my old e-mail. Whoops!
  • DoD only offers certs for two uses: e-mail signing/encryption and SSL encryption. It would be nice to use IPSec, but they don't offer IPSec certs.
  • Oh, right... the reason they don't offer IPSec certs is because they have no plan to automatically distribute machine certificates. That and the above-mentioned ban on widely-available soft certs.
  • It doesn't address DMS at all. If you don't know what DMS is, think of something that's kind of like e-mail, but much more important. It replaced the old autotran system, for you old-schoolers (and frankly, autotran works better, but that's for another day).
  • That's all I can think of right now, so I'll mention my office joke that never gets old. Our USB SC readers are made by a company called "Cherry", so we always have to stick our CACs in the Cherry. :-}
The DoD PKI rollout was "successful" in that it met deadlines (sort of) and came in under budget (kind of). But they were only able to do this by choosing to address a very narrow segment of the problem, and ignoring (in some cases, to the detriment of a real solution) any problem that was deemed too difficult.

--
All God's critters got a place in the choir
Some sing low, some sing higher
Hmm, you sound a bit jaded. (2.25 / 4) (#6)
by imrdkl on Wed Feb 18, 2004 at 12:17:29 PM EST

First, thanks for an excellent overview of how things really work. I was perhaps a bit optimistic in declaring the operation a success, although to be fair, any PKI which goes beyond the stage of MS Word documents can be considered at least a partial success. Nevertheless, I'd like to get some additional feedback on some of what you said.

There exists no PKI trust chain outside the root CA and a intermediate CAs used by the folks at the PKI SPOs.
This is true. If you click the "simplified process" link above, and validate the certificate chain for the setdweb.setd.army.mil server cert, it's clear that the NSA root is only three levels deep, even though I don't have that root installed. (Will you post it as pkcs7?) The server CA for the setdweb is indeed a intermediete level CA. I suspect that this is mostly due to limited support for depth > 3 in MS products.

PKI isn't integrated with our directory structure. Oh, wait, that's because we don't have a directory structure yet. At best, there are several un-related forests, which they plan to link together using a meta-directory service. Oh, that sounds like a great idea!
Again, referring to the setdweb certificate above, it appears as though the directory structure does exist, with LDAP urls given for issuer alternative name URI and CRL distribution points. I don't know if either of these URI's actually function, however. Perhaps you could test them.

I saw you said something about CRLs, but DoD PKI hasn't implemented CRLs in any meaningful way, yet. (They can't without the above-mentioned meta-directory, and probably a meta-meta-directory.) So instead, in order to validate certs, each base downloads a (currently) 28GB file from their branch SPO with a list of valid certs.
Yes, Nolte acknowledges this, and it's covered above. Most importantly, the fact that some applications aren't bothering with the CRL lookup at all.

The current CAC cards have only 16KB of memory, which isn't really useful for much other than storing a few certs. They want to store things like medical records, which requires replacing all existing cards.
It's reported, again under the "simplified process" link to setdweb that the cards may contain RFID and plenty of other functionality, some of which can only imply 32 or 64 kb smart cards. But hey, you can't get into smart cards without getting a few batches of the previous generation (the same applies for cardreaders, at least in the SIMcard world).

There's currently no way to sign messages from an organizational mailbox. DoD PKI policy is to not issue soft certs (ie, private key in a file instead of on a SC) which would allow us to do this. Hint: all important e-mail traffic comes from organizational boxes.
If you'll read Nolte's interview, all the way at the end, he does mention that group certificates are in the works.

My CAC card has my current e-mail address hard-coded into it. My e-mail has my base name. When I PCS in a few months, I'll have to get new certs. When I get new certs, I'll no longer be able to decrypt my old e-mail. Whoops!
This would be a shame, if true. As you're no doubt aware, the encryption of your email has nothing to do with the certificate itself, only with the public key which is embedded in it. That key, along with your private key are independent of the certificate, and can be reused to obtain a new certificate. In fact, assuming that the CA retains the PKCS10 certreqs, there's no reason why they can't re-sign the original certreq, although some embedded information may require a new req.

DoD only offers certs for two uses: e-mail signing/encryption and SSL encryption. It would be nice to use IPSec, but they don't offer IPSec certs.
I think you're being a bit, uh, harsh here. Rolling out the email encryption was likely a bigger task, in terms of user support and training than anyone of us here can imagine. Small steps, eh? Once the support mechanisms are in place for email, it should be a snap to extend that to IPSec. Remember also, your client cert (identity cert) has the capability to do more than just what MS Certificate Explorer says it can do. I haven't actually seen a DoD client cert, but simple IPSec doesn't require CRL signing, only key encipherment and digital signature.

Oh, right... the reason they don't offer IPSec certs is because they have no plan to automatically distribute machine certificates. That and the above-mentioned ban on widely-available soft certs.
Again, I'm not sure about the key usage requirements for IPSec certificates, but machine certs are likely analogous to SSL server certificates (at least on the server side). Extending key usage of client certificate to IPSec is, I think, trivial.

That's all I can think of right now, so I'll mention my office joke that never gets old. Our USB SC readers are made by a company called "Cherry", so we always have to stick our CACs in the Cherry. :-}
:{)

[ Parent ]

Jaded? Yeah, I guess (2.25 / 4) (#9)
by curien on Wed Feb 18, 2004 at 02:39:55 PM EST

Between the halfway implementation of PKI and the halfway implementation of AD, there's a lot of functionality that we should be able to use but can't. If I'm a little jaded, it's due to my recent difficulties over the last few weeks.

I agree that simply getting the SCs rolled out was a huge undertaking. Every military member, civil service civilian, and contractor needed to be issued certs, and they actually managed to distribute them on-time.

You asked if I could post the DoD root cert, but I'm not sure if I can. I mean, I can (even though it'd be a pain -- I'm on leave and using my gf's computer, so I'd have to VPN into work to get it), but I'm not sure if I'm allowed to distribute it. (Why not? you ask... who knows, this is the gov't.) For those of you with .mil domain names, you can get it from the AF PKI SPO. (I can't view the site right now, but IIRC, click on "workgroup managers" or something.)

A lot of the problems I mentioned have solutions in the works (as you mentioned for organizational certs), but they're not here yet, and they really are critical. Lots of apps in DoD distribute usernames and passwords (wait, wasn't PKI supposed to allow single-sign-on?) via e-mail, and it's currently not possible to sign or encrypt those messages. My office, for example, does all business through an organizational box, and it would be nice to be able to sign our e-mail.

I also forgot to mention that our webmail currently doesn't support S/MIME. I know, I know... wait for Exchange Titanium (or whatever it's called now). But in the meantime, we have a moratorium on actually using signed e-mail because people got sick of not being able to read anything through webmail. (So actually, signed e-mail isn't really "delivered" yet.)

Yes, my e-mail is really hard-coded into the cert, and the AF (unlike some other branches) still uses a user@base.af.mil address scheme (instead of user@af.mil). The "fix" is to no longer require that the e-mail address on the cert match the recipient address. We're sacrificing a good chunk of security in order to jury-rig a solution to a problem that should have been solved prior to the roll-out.

My biggest beaf really is the machine certs, and it's because I manage servers. Yes, you can acquire certs for web servers, but they're useless with IPSec (I don't know why... I'm working with the AF PKI SPO to get the situation corrected). But even if we do find a solution, we can't manually request machine certs for every single computer in ACC (which really is what I want, in an ideal world). Currently, there aren't even plans to roll-out machine certs to every machine. As things stand, where we need to use IPSec, we use a command-wide pre-shared secret (you'd shit yourself if you knew what it was). That's Bad Juju.

Yes, the certs all have LDAP addresses for CRLs and what have you, but the LDAP infrastructure doesn't exist yet. The URIs point into the ether. (Well, not quite, but until the meta-meta-directory gets set up, it's unavailable to anyone outside a branch-level SPO).

--
All God's critters got a place in the choir
Some sing low, some sing higher
[ Parent ]

More questions, and an easy solution (none / 3) (#10)
by imrdkl on Wed Feb 18, 2004 at 04:23:02 PM EST

You asked if I could post the DoD root cert, but I'm not sure if I can. I mean, I can (even though it'd be a pain -- I'm on leave and using my gf's computer, so I'd have to VPN into work to get it), but I'm not sure if I'm allowed to distribute it. (Why not? you ask... who knows, this is the gov't.) For those of you with .mil domain names, you can get it from the AF PKI SPO. (I can't view the site right now, but IIRC, click on "workgroup managers" or something.)
I'm pretty sure that it'd be just fine. By visiting the setdweb linked above, anyone gets access to their SSL server cert, along with the (DOD CLASS 3 CA-4) intermediete CA signing certificate. The only one missing in the chain from there is the NSA root, I think. If I could take a look at the root, then I'd have a much better idea of what this PKI is actually capable of. It's also pretty easy to export a copy of the root from IE, and without using your VPN connection to download it, as long as you've installed it on your gf's computer.
IE->Tools->Internet Options->Content->Certificates->Trusted Root Certificates
Double click the NSA root cert, click the details tab, and then click the "copy to file" button. This will open the cert wizard, click Next, then save as Base64 encoded x509. The resulting text file can be easiy opened with wordpad and pasted in as a comment (use plain text mode to retain the formatting). If you're not comfortable doing so, I'll understand, but you shouldn't need to redistribute anything from the internal .mil web, and it would be very interesting.

Yes, my e-mail is really hard-coded into the cert, and the AF (unlike some other branches) still uses a user@base.af.mil address scheme (instead of user@af.mil). The "fix" is to no longer require that the e-mail address on the cert match the recipient address. We're sacrificing a good chunk of security in order to jury-rig a solution to a problem that should have been solved prior to the roll-out.
Working out the issues involved in unified mail addressing, especially in such a large organization with undoubtedly massive namespace conflicts (John Smith, etc) should indeed be finished before a PKI gets started, but as we both know, if the PKI had to wait for that, it'd never get started. Anyways, if they'll let you reuse your existing keys for your new cert, you can still decode your old email. But even that possibility might not be available, given the escrow nature of the CA. Escrow CAs are pretty dumb to begin with, but I guess that's for another discussion.

My biggest beaf really is the machine certs, and it's because I manage servers. Yes, you can acquire certs for web servers, but they're useless with IPSec (I don't know why... I'm working with the AF PKI SPO to get the situation corrected).
This is purely a function of the key usage which is enabled at signing-time. But without the root certificate, we cant tell if the CA has granted itself the necessary authority to create other types of certificates.

But even if we do find a solution, we can't manually request machine certs for every single computer in ACC (which really is what I want, in an ideal world). Currently, there aren't even plans to roll-out machine certs to every machine. As things stand, where we need to use IPSec, we use a command-wide pre-shared secret (you'd shit yourself if you knew what it was). That's Bad Juju.
That is scary, even for a Bush-basher like myself. :) I'm not familiar with IPSec, but is it not possible to start the stack running after somebody (with a client certificate) logs on, and can use their own certificate to act in the role of the machine certificate as long as they're logged on?

[ Parent ]

Subject goes here (none / 2) (#13)
by curien on Wed Feb 18, 2004 at 05:27:02 PM EST

The DoD root isn't on this computer, so I can't export it. :-} I know you can get the intermediate CA and public server cert, but as they've chosen to put the root CA on a .mil-only webserver, I'll leave it there until I hear I can do otherwise (I will check for you, though).

As for IPSec, it has to use machine certs, where the public and private keys are both stored on the machine. It cannot use a portable key solution like SCs at all (at least, I can't think of a very good way to do so), so the attack you described isn't applicable.

--
All God's critters got a place in the choir
Some sing low, some sing higher
[ Parent ]

I understand (none / 2) (#14)
by imrdkl on Wed Feb 18, 2004 at 05:39:52 PM EST

Thanks for the insights. If you can get permission, it'd be interesting for sure.

[ Parent ]
Hi Again (none / 1) (#19)
by imrdkl on Thu Feb 19, 2004 at 06:00:35 AM EST

Um, I wonder if you'd be willing to contact me offline about this? I think we should talk privately about some things. Send mail to MYNICK@MYNICK.homelinux.com, asap, if you please?

[ Parent ]
I think I can safely say (none / 0) (#27)
by imrdkl on Thu Feb 19, 2004 at 05:13:15 PM EST

That your call for IPSec and even more security has now been escalated. :)

[ Parent ]
More questions, and an easy solution (none / 1) (#34)
by dleach on Fri Feb 20, 2004 at 11:25:01 AM EST

curien states, "Yes, my e-mail is really hard-coded into the cert, and the AF (unlike some other branches) still uses a user@base.af.mil address scheme (instead of user@af.mil). The "fix" is to no longer require that the e-mail address on the cert match the recipient address. We're sacrificing a good chunk of security in order to jury-rig a solution to a problem that should have been solved prior to the roll-out."

Disabling name checking in MS Outlook does not weaken the security of digitally signed or encrypted e-mail for the following reasons:
* Access to the Private Key still requires the correct PIN to utilize the PKI certificates on the CAC.
* The digital signature still ensures data integrity, identification and authentication of the message originator, and provides non-repudiation.
* A recipient's e-mail client can still verify the digital signature to ensure the message has not been altered in transit and that the sender's certificate is current, trusted and not revoked.
* Encryption still ensures confidentially of the message content, including attachments.
* The S/MIME standard does not mandate name checking for S/MIME enabled e-mail clients.

Where are we "sacrificing a good chunk of security"?  Was disabling name checking what you were talking about when you said "The fix is to no longer require that the e-mail address on the cert match the recipient address"??


[ Parent ]

Not security of stealing a private key (none / 0) (#39)
by curien on Tue Feb 24, 2004 at 10:30:54 PM EST

but there's an added bonus in ensuring that the certificate is actually used with the e-mail account it was signed for. It's not a huge thing, but it's another hoop to jump through for someone trying to spoof a valid user.

--
All God's critters got a place in the choir
Some sing low, some sing higher
[ Parent ]
Correction (none / 1) (#17)
by sil on Thu Feb 19, 2004 at 02:49:22 AM EST

Don't know where you got your 16KB info from, when you stated current CAC cards have only 16KB of memory, which isn't really useful for much other than storing a few certs. There are plenty of cards which stretch out to 64KB: ActivCard Gold, Activ* Smart Card 64K, Cyberflex Access 64K...

There are also 128 cards available, it's just the DoD doesn't seem to want them. "Paul Beverly, a vice president at SchlumbergerSema, North America, said his company already has a 64K card and a 128K model on its roadmap, but that memory isn't really the issue with DOD." Federal Computing Weekly The DoD already has 64KB cards in use in case you didn't know.

Aside from all this boring compsec talk, if they really needed to, the DoD could always go with the NSA's MISSI scheme

[ Parent ]

I have an early card (none / 0) (#26)
by curien on Thu Feb 19, 2004 at 04:46:35 PM EST

Langley was a test base, so my card is older than most. Yes, larger cards exist, but DoD isn't using anything larger than 32KB yet (and most are still 16KB) on a wide scale (I don't know anyone with a 64KB card). There are plans to use larger cards in the future; it will require replacing all the cards we just got done distributing.

Never heard of MISSI.

--
All God's critters got a place in the choir
Some sing low, some sing higher
[ Parent ]

say what? (none / 0) (#28)
by sil on Thu Feb 19, 2004 at 07:57:39 PM EST

Never heard of MISSI? I hope you're kidding me. Hell I'm not even in the military, nor any form of government related company, and I probably know stuff their own don't. What about OSIS stuff via NIPR... Are you new in the mil||gov or something?

Time for some schooling

At least tell me you get to play with a GETAC, or an encrypted blackberry. KG95's?

[ Parent ]

OSIS, yes (none / 0) (#29)
by curien on Thu Feb 19, 2004 at 11:07:12 PM EST

After some looking, MISSI is the NSA's approach to MLS, which is something I'm familiar with, though I don't really deal with that kind of thing.

--
All God's critters got a place in the choir
Some sing low, some sing higher
[ Parent ]
problem. (1.00 / 5) (#15)
by fae on Wed Feb 18, 2004 at 07:20:47 PM EST

Through heavy computation, a private key can be obtained. Identities can be stolen.

-- fae: but an atom in the great mass of humanity
Not really (2.20 / 5) (#18)
by Highlander on Thu Feb 19, 2004 at 03:57:50 AM EST

When RSA is used the keys can easily be made so large that simply brute-forcing the way through the keyspace is not feasible.

The prime numbers used to construct the keys in fact are so large that a semi-random process is used to get them. Even just producing the prime number the usual way ( some kind of sieve ) would take too much time.

Of course we don't know whether there exists some kind of trick but primes are kinda random and that trick is unknown.

Moderation in moderation is a good thing.
[ Parent ]

setdweb has been taken down (none / 2) (#20)
by imrdkl on Thu Feb 19, 2004 at 08:32:44 AM EST

The link above under the text "simplified process" has now been restricted. I regret that the military has resorted to this action, but it does seem the most appropriate temporary measure. I hope that when some information which was inappropriate for public access is removed from that site, that public access will be restored.

Hooray! It's back up. (none / 2) (#21)
by imrdkl on Thu Feb 19, 2004 at 08:48:09 AM EST

The inappropriate file has been removed, and access has been restored to the public.

[ Parent ]
Now down again (none / 1) (#35)
by imrdkl on Fri Feb 20, 2004 at 11:41:16 AM EST

Not actually down, but now restricted from all non-military access. Too bad, it was admirable that the military felt confident enough in their PKI to place its documentation on the web.

[ Parent ]
It's all just (1.75 / 3) (#22)
by daragh on Thu Feb 19, 2004 at 11:25:54 AM EST

Boys with toys. Ooh, guns! Ooh, magic cards!

Militarilarily cynically yours,

No work.

Redundant (1.25 / 4) (#24)
by Xcyther on Thu Feb 19, 2004 at 01:43:06 PM EST

Calling it a CAC Card is redundant. Since the last C in CAC stands for card. Its like saying NIC Card or ATM Machine or PIN Number.

_________________________________________
"Insydious" -- It's not as bad as you think

You've made my point for me.. (none / 1) (#30)
by tiamat on Fri Feb 20, 2004 at 12:30:38 AM EST

Yes you're right about it being redundant, but as you're pointed out, it's the lingual norm in English to do it the way this author did. Anyone who refers to a PIN as a PI number or an ATM as a AT machine would be considered daft by most, if not all, English speakers.

You're right, but more importantly, you're wrong. Stop being so annoying about it.


[ Parent ]

Thats why (none / 1) (#37)
by Xcyther on Fri Feb 20, 2004 at 03:07:53 PM EST

You just dont say the last word twice. You refer to it as an ATM, such as "Do you know where the closest ATM is?" Or "Can you please tell me your PIN." Thats why they made acronyms out of them - so you dont have to say the words. Its not that hard, and you get to be gramatically correct. Imagine that.

_________________________________________
"Insydious" -- It's not as bad as you think

[ Parent ]
Huh? (none / 0) (#38)
by skintigh on Tue Feb 24, 2004 at 12:50:52 PM EST

Only an idiot says "ATM machine" instead of ATM or "PIN number" instead of "PIN."  That's like saying "Lets go watch TV vision."

Therefore only a moron says "CAC card."  This is verified by who at work says "CAC card" instead of CAC.

[ Parent ]

More information (none / 1) (#25)
by imrdkl on Thu Feb 19, 2004 at 02:07:54 PM EST

A good, in-depth study of the entire DoD PKI program is available here, in PDF form. The document, written by one Major Alan Gunnerson for the MBA IT program at UTDallas is entitled, "Army Internet-Based Training: Public Key Infrastructure And Information Security Requirements", and includes an historical perspective on what drove the military to adopt PKI, along with more information on the CAC, and a few other programs within the distributed-learning purview. Quite informative. As it turns out, another one of the driving forces behind the rapid deployment of PKI was a report by the U.S. Congressional Subcommittee on Government Efficiency, Financial Management and Intergovernmental Relations, which flunked 16 US government agencies on security efforts.

Verisign wins award (none / 1) (#31)
by koffie on Fri Feb 20, 2004 at 07:13:16 AM EST

Read about it here. Dunno offhand if this is PKI related, but the motivation for the award appears to be "their presumption that they own the internet and the domain name system hijacking scandal". Close enough for me. ;-)

such a good write-up ... sigh... kudos (nt) (none / 2) (#32)
by mami on Fri Feb 20, 2004 at 07:22:38 AM EST



PKI is overrated (none / 2) (#33)
by Quietti on Fri Feb 20, 2004 at 09:38:03 AM EST

Even though "centralized everything" is politicaly desirable (politicians want a master on/off switch to everything), it however is technically undesirable, because a CA is inhenrently a single point of failure. As such, PKI itself is a big no-no.

--
The whole point of civilization is to reduce how much the average person has to think. - Stef Murky
PKI newbie (none / 1) (#36)
by ckaminski on Fri Feb 20, 2004 at 12:12:17 PM EST

What's to stop from having multiple peer CA's?  I can understand a single-root based structure being bad, but having several peers would certainly improve the odds, no?  And cannot child CA's live independently of the root?  

[ Parent ]
there could be child hosts and redundancy (none / 0) (#42)
by Quietti on Wed May 26, 2004 at 03:53:34 AM EST

but every request I've had vehemently opposed to that. They want one single "beast" to rule them all. I refuse to implement failure.

--
The whole point of civilization is to reduce how much the average person has to think. - Stef Murky
[ Parent ]
PKI adequate for government work? No. (none / 1) (#40)
by mdevo on Fri Feb 27, 2004 at 12:01:25 PM EST

The PKI safety function of archiving your private encryption key is problematic. Common folks are protected against their failings and the government can ensure security and surveillance. It is our job. However, the Digital Signature Law prevents archiving of your private signature key for good reason. This allows budding spies and crooks to create and use programs that use the private signature key to encrypt information. How does the government then do its necessary security job? Fortezza (HW encryption / key escrow) was a lame idea, but the better idea in light of the PKI empire collapsing under its own mass.

PKI based on RSA? (none / 1) (#41)
by thogard on Sat Feb 28, 2004 at 05:05:48 AM EST

Is your PKI based on RSA?

RSA is based on a concept of Euclidian algorithm
and if you do it the hard way, you may find that that public to private keys aren't 1:1 but more like one to many.

If so take a look at at:
http://www.abnormal.com/~thogard/rsa.pl
which is a bit of perl code that shows the concept.


Problems and Promise in the World's Largest PKI | 42 comments (32 topical, 10 editorial, 1 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!