• Enable passcode/lock

Mobile phones have had passcode capabilities for a long time. Make sure you’re using it, since a passcode lock is often the first line of defense.

• Erase all data before a return, repair, or resale

If you will no longer be the owner in possession of the device, it’s best to erase everything you can first. Everything. If you can do a factory reset, do so, because your phone constantly records information and there is always some data that isn’t easily found, let alone purged.

• Regularly update firmware

I’m guilty of not doing this– sometimes the update notification will sit around for a week before I finally give it permission to run. But this is one of the easier things to do, since it’s mostly automatic.

• Don’t run shady apps

Just like with a personal computer, if you run unknown or untrusted applications, you substantially increase your chances of getting got. So if you don’t want to get got, be prudent about what apps you run on your device.

• Take advantage of the web browser’s security

For smartphones with native web browser apps, be sure to use the security features to clear caches and stored passwords when it’s necessary. Just because a web browser is on a mobile device doesn’t mean it’s a security lightweight. Check out the “settings” or “options” to see just how much your mobile phone web browser can do to help you out.

• If you’re not using it, disable it

I’m also guilty of leaving stuff running unnecessarily. Be careful about leaving debug mode enabled, Bluetooth and wifi on, etc. Generally speaking, the more doors you leave unlocked, the lighter you sleep at night. Turning off unused services when they aren’t needed is a good habit to form, even outside the realm of security.

• Secure that email

In addition to providing native web browser apps, many smartphones also come bundled with a native email app. Check the settings for these apps to take advantage of any security features they’re offering (such as SSL/TLS).

• Use a phone tracker

The GPS can be bad for privacy if you are reckless with it. However, it can also be a powerful tool to help you recover a lost/stolen device. I believe the iPhone 4 has a built in device-finding service (complete with a remote wipe). But even if you have a different smartphone, there is almost certainly an app that provides some remote tracking for lost devices (i.e. Where’s My Droid app for Android).

This certainly isn’t a comprehensive list, but it should be enough to get both new and old smartphone users thinking about general mobile device security in a healthy way.

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

The Underground Economy: Priceless (pdf) touches on the subject in a great amount of detail, even explaining the importance of reputation and the lengths people take to avoid prosecution.

Essentially, public and private servers host communities of individuals who offer their services for a fee. Maybe one person will help someone else cash out an entire bank account (for a 50% cut). And maybe another person will deliver ill-purchased goods to a safe location (for a 30% stake). In the mix are also those who initially did the work (or wrote the code) to capture the information, as well as people who specialize in forging IDs, curious researchers, law enforcement… the list goes on. Compromised financial data seems to lead to a very deep chain of events that attracts many people with varying skillsets, most of whom are simply offering to perform the same hustle(s) over and over. It is a system where both information and skills are bartered/exchanged and high risk is accepted for high returns on investment.

But not all participants are highly skilled– there should be some low-hanging fruit in there too, right? Surely, there are people who aren’t as cautious or who miscalculate their risk of exposure, yet we still have trouble keeping up with even a fraction of the online fraud. While I’m glad we are focusing efforts on preventing information from being compromised in the first place, I feel like there is a growing opportunity to focus a lot more research on thwarting these high-risk behaviors directly. Sometimes you have to treat both the symptom and the cause.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK

1. Move the jar into the $JAVA_HOME%\lib\ext folder. It’s most likely in a place like this:
    

   C:\Program Files (x86)\Java\jre6\lib\ext\

    

2. Connect your USB cable to your phone and verify with adb that it is seen as attached. [%android-sdk% is the location of the Android SDK installed on your system]
    

   %android-sdk%\tools> adb devices

    

3. You’ll need to grab the cacerts.bks file from your phone using adb:
    

   %android-sdk%\tools>adb pull /system/etc/security/

   cacerts.bks cacerts.bks

    

4. Now let’s extract the cacerts.bks to a human readable format (there are other ways of reading bks files, but this is an easy route)

 

%android-sdk%\tools>"%JAVA_HOME%\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-list > calist.txt

 

5. Open the newly created calist.txt file and search for the desired CA Cert ( DigiNotar CA in our case). You’ll want to identify the alias name number. You’ll use this to identify the certificate so that you can remove it with keytool.exe:

 

*******************************************
Alias name: 61

Creation date: Feb 8, 2011

Entry type: trustedCertEntry

Owner: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Issuer: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Serial number: c76da9c910c4e2c9efe15d058933c4c

Valid from: Wed May 16 17:19:36 UTC 2007

until: Mon Mar 31 18:19:21 UTC 2025

Certificate fingerprints:

MD5:  7A:79:54:4D:07:92:3B:5B:FF:41:F0:0E:C7:39:A2:98

SHA1: C0:60:ED:44:CB:D8:81:BD:0E:F8:6C:0B:A2:87:DD:CF:81:67:47:8C

Signature algorithm name: SHA1WithRSAEncryption

Version: 3
*******************************************

 

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce.

provider.BouncyCastleProvider -storepass changeit -v -delete

-alias <alias name number>

 

For example:

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-delete -alias 61

 

You’ll probably want to repeat this process for the Comodo certificates as well if you’re really security minded (of course you are).

6. Once you’ve removed the certificate you can push the cacerts.bks back to your phone for usage:

 

%android-sdk%\tools>adb remount

 

%android-sdk%\tools>adb push cacert.bks /system/etc/security/

 

7. The final step will require you to reboot your phone so that Android can reload the cacerts.bks.
8. Enjoy!

If you have root access and don’t feel like going through ADB and all the SDK installation, the GuardianProject has created an Android app (CACertMan) that is targeted at doing the above for you and letting you manage your certs yourself. You can check it out here. It is still in beta and isn’t 100% compatible yet, hence the manual instructions above.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists.

What does this mean?

SSL, or TLS, is used to perform two things. First, it provides authentication of the web server to the web browser. (It can optionally provide authentication of the browser to the server, too, but that’s less common.) This means that the web browser knows that it is talking to a trusted web server and can share sensitive information with it. Second, it provides transport-layer encryption, so that the communications between the web browser and the web server are encrypted. This means that other parties cannot read what is being sent between the server and browser. This is widely used for most logins, because you don’t want your username and password being sent to the server “in the clear”. Anything sent “in the clear” can be read by anyone else on your network (or within range of your wireless network), or by anyone on any network that your traffic is routed through between you and the server.

In this case, a fraudulent certificate has been issued for *.google.com by a certification authority which is completely trusted by most modern web browsers. This means that the web browser will see this certificate, consider it valid for all traffic with Google (and GMail), and go ahead and create that little lock icon everyone has been trained to look for, which indicates your communication is secure.

Except, it’s not.

Google does not own this certificate. Google did not pay for this certificate. Therefore, when you communicate using this certificate, it’s not with Google. It’s with whoever managed to get that certificate issued, which according to the pastebin, is by groups wishing to do harm to individuals in Iran.

Personally, I don’t want to take a chance on whether it might be used against me, as well.

What should I do about it?

It is my opinion that issuance of a certificate such as this is an unforgivable sin.  Certification authorities must have the appropriate technical controls, and checks and balances, to prevent this from ever happening. There are plenty of certification authorities out there, and it is time to remove this one from my system and all systems I manage.

The good news is that the browser manufacturers also think this is a bad thing and are rushing to put together information on how to ensure you won’t trust this certificate.

• Mozilla is updating Firefox, Seamonkey, Thunderbird, and others to remove this; they also provide a link for manual removal.
• Apple hasn’t stepped up with information about it yet that I can find. If you’re running a Mac OSX machine, you should set your system to never trust the Diginotar certificate. Run Keychain Access, and on the left choose your “login” keychain. Down below, choose “All Items”. Then in the search box, search for DigiNotar. You should see one or two results for DigiNotar Root CA. Double-click it. Expand the Trust arrow, and where it says “When using this certificate:” choose Never Trust. Close the window and you will likely be prompted to enter your password to update the login keychain. Repeat for all occurrences of DigiNotar certificates. Update: It’s worse than I thought. This method does not work for EVSSL certificates in Safari. See this link for more information. Stay tuned for any updates Apple might make about this, a patch to Safari is probably necessary.
• Microsoft tells you you’re protected if you’re running Vista or later. If you’re not and still running XP or Windows 2000/2003, you should remove the certificate manually. The easiest way to do this is to launch Internet Explorer, and choose Tools->Internet Options. (Or just launch “Internet Options” from your control panel.) Go to the Content tab and click the Certificates button. Click the Trusted Root Certification Authorities tab. Find the DigiNotar Root CA and double-click it. (If it’s not there, you’re safe!) Click the Details tab and click the Edit Properties… button. Choose Disable all purposes for this certificate and click OK.
• Google Chrome users, you will benefit from the rapid updates to Chrome which will mark DigiNotar as untrusted. You can (should?) also take the Apple or Microsoft manual removal steps above to be sure you’re safe.

Additional good commentary (as always) from Moxie Marlinspike and Jacob Appelbaum.

This is a pretty sweet hard drive, but there are a few annoyances that I think can be improved upon. I was unable to test a few things just due to the time I could devote to this, the fact that I need to return the drive in working condition, and that I don’t have access to some specialized hardware to test timing attacks.

The drive is FIPS 197 validated – aka, uses AES according to NIST.

You can check out Apricorn’s site for the specs and details, but what you see on the product site is pretty much what you get. The drive draws power from your USB port, so you’ll need a powered port. The drive came with an adapter (1 USB to 2 USB) if one of your USB ports doesn’t provide enough power. I had no issues with power on my MacBook Air, but I did on my office desktop since all USB ports were already taken – easily solved with a powered USB hub.

The drive comes formatted for Windows, but my mac helpfully formatted it for me once I said “yes” to “Use this as a Time Machine drive?” The quick start sheet in the box also provides Mac formatting instructions. The actual manual is already on the drive, and my mac helpfully erased it for me during formatting. However, the “Support” section of the website has the full manual available for download. At first, you really want to have the full manual available (and not on the drive).

The drive has the capability to have an administrator PIN and up to 9 “user” PINs. Knowledge of the admin PIN can wipe the user PINs, but not change them – only users can change their PINs. The different PINs do not allow access to different parts of the drive. All PINs have access to the entire drive. PINs can be anywhere between 6 and 16 digits, the default admin PIN is 123456 and there are no user PINs. There is “drive wipe” protection, but it’s pretty lame, and wouldn’t meet most corporate policies (complaint #1). After 6 invalid PIN attempts, the drive needs to be unplugged before you can try 6 more attempts. Once you’ve gotten to 50 attempts, you have to type in a (hardcoded) PIN to try 50 more times (you still have to unplug every 6 tries). Only after 100 total attempts will the drive “wipe” itself. Given how long the wipe took during this testing, it’s probably only wiping the keys, not the whole drive (but the manual doesn’t say this is the case). While annoying, certainly not insurmountable for someone who’s really determined, but a brute force for a 6 digit PIN (the minimum) is 10^6 – well over 100, so unless the attacker has some prior knowledge, the drive will likely wipe first.

Basic operation is plug in drive, enter a valid PIN (user or admin) and the drive mounts – decrypted. When you’re done, unmount the drive from your OS, and unplug the drive. Until you unplug the drive, the data is still decrypted (complaint #2).

The administrative “interface” works, but it’s pretty complicated – hence my suggestion to keep the manual handy until you’ve got the hang of it. All commands are sent using a keypress combination or sequence. Granted, the primary interface is a keypad with a “cancel” and a lock icon in addition to the 10 digits, and you’re limited a bit. I had some trouble creating user PINs, but it seemed intermittent, so I blame it on user error instead of anything the drive did (or didn’t do).

If you forget your PINs, you’re SOL (which is as it should be – in most cases). You can reset the drive back to factory settings – again, the “wipe” is just a wipe of the keys and partition table based on the time it took. This is great for most uses, but I can see corporate folks leery about this because if a user forgets their PIN (or tries to reset their drive themselves), the company’s just lost a lot of data. The admin PIN is supposed to protect against that and as long as help desk/etc. keep that PIN, they’re safe from all but others resetting the drive.

The keypad is supposed to be wear resistant – but in the two weeks I had the drive, I can’t test that, but it feels sturdy, and the digits seem to be embedded in the rubbery keys.

The casing appears sturdy and no obvious screws (they’re probably under the rubber feet), but since I have to return it in working condition, I didn’t try too hard to break the case. There is no special padding or ruggedness to the case that you wouldn’t see in an unencrypted external drive case. However, the product page claims some protection from drops (I’ve found that most external drives can handle a small drop).

There’s also VTC (Variable Time Circuit) technology, which I’ve never heard of, but apparently helps to thwart timing attacks – again, not something I can test, because I don’t have the equipment (or time).

It’s pretty easy to use, and I used it almost daily for two weeks – mostly for play, since I don’t have a real need for external drives (except Time Machine). The drive is on my wish list, but until I get my house sold, we’re on a spending moratorium at home. It’s really not that expensive relative to unencrypted drives – the AES-256 250GB drive is listed at $109. There’s a 3 year warranty on the drive, which covers the drive and the casing.

The drive’s a bit slower than your typical external drive, but I expected that. An initial Time Machine backup of 198GB took 4.5 hours. I was using the computer while it was backing up, so that could have impacted the performance. For most uses, you won’t notice much of a difference – unless you’re moving a *lot* of data that has to be encrypted on the drive.

There are a few annoyances, but they’re really just annoyances.

1: Having to unplug the drive to lock it. There’s already a cancel button, why not use that for a “lock” button. As long as the drive is receiving power – say, while the computer has the screensaver turned on, the drive remains decrypted. Now, someone can’t easily read the drive if the screen is locked, but if someone doesn’t lock their screen? It’s available. There’s also no “timeout”. I can see why – as long as the OS has the drive mounted, it could be in use. I wonder if it’s possible for the drive to detect that it’s been unmounted and lock itself after a pre-determined time.

2: It’d be nice to have a configurable wipe after X attempts capability – or at least wipe after 10-15 attempts, which would cover most corporate policies.

3: I would love to see a Kensington style laptop lock on the drive case. The data may be protected if someone steals the drive, but it’s annoying. As I can see this drive going along to the library/coffee shop/etc. with the laptop, it’d be nice if there were some physical way to lock the drive either to the table or to the laptop. You should never leave your laptop/data/”stuff” unattended in public places, but a lot of people do it.

Now, the biggest loss from someone stealing my netbook is in data; the hardware really isn’t all that expensive. My netbook doesn’t just contain personal information; it’s also full of important business data. I can and do perform regular backups to make sure I don’t lose any of the data, but I don’t want anyone else reading what I’ve got, either.

That’s where file encryption comes in. If properly encrypted, my data won’t be accessible even if someone has the hard drive. So, with that in mind, I’m looking at three different utilities for encrypting my drive:

TrueCrypt – TrueCrypt is kind of the grand-daddy of Whole Disk Encryption; it’s currently on release 7. Being free for download, it’s rather popular. It offers a range of features, including the ability to perform whole disk encryption, and the ability to create hidden volumes and hidden operating systems, meaning that even if you’re compelled to divulge passwords, your attacker won’t know about these volumes and thus won’t know to get access to them. In addition, TrueCrypt comes with a pretty impressive set of encryption algorithms, including AES-256.

AxCrypt – Another piece of freeware, AxCrypt doesn’t offer quite as much as TrueCrypt. Unlike TrueCrypt, AxCrypt exists for encrypting files and doesn’t have a whole disk option. Also, it’s limited to AES-128 which is not bad but certainly not as secure as 256. It seems to have a bit more open UI, however, letting users execute scripts on it. It’s also more oriented toward online shares and network storage – so if you want to put encrypted files on online repositories, AxCrypt may be the one for you.

PGP – The third tool I’ve been looking at is Symantec’s PGP. Unlike the other two, PGP costs – roughly 90USD per license. What do you get for $90? Well, it looks like it’s not a bad piece of software. As with TrueCrypt, Whole Disk Encryption is an option. It also has centralized management options, so it seems the best of the three for large-scale implementations. In addition, it has a host of certifications, notably FIPS 140-2 compliance. If you’re in an environment where that’s required, this is likely the way to go. While the online information is not immediately forthcoming on encryption algorithms, FIPS-140-2 compliance means that at minimum it offers AES-128.

For my purposes, I’m likely going to use TrueCrypt. AxCrypt and PGP both have their place. But the most important thing? Implement something. It’s easy to put off such a step, but you never know when your mobile device might be lost or stolen.

It also sets the stage for wider adoption of EHR in the private sector. But there are reasons to be concerned about this, of course. There are few, if any, pieces of information more intrinsically private and personal than one’s medical records. And while making these records available in an electronic format offers great advantage in medical care, it opens up great risk of compromise.

As with any important data, there are ways to provide EHR. The medical industry in America is very heavily regulated, with HIPAA being the primary source of guidance. Based on HIPAA and related laws and regulations, various healthcare-related certifications exist. The two with which I am most familiar are DIACAP and CCHIT.

DIACAP stands for Department of Defense Information Assurance Certification and Accreditation Process. It’s not specific to medical information, but it is specific to DoD systems. It’s important here because most publicly-available EHR systems will have descended from DoD systems which had to pass DIACAP. DIACAP is a very intensive process which takes reams of documentation and months of work. It’s very comprehensive. Unfortunately, because of how it’s designed it can sometimes be outdated, and even force systems to be insecure. For example, at least as of 2010 when I last worked with it, systems were required to use Internet Explorer 6, with all the limitations of that browser. Nothing newer was possible.

Outside of the DoD, I’ve also worked to certify systems under CCHIT standards. CCHIT stands for Certification Commission for Health Information Technology, and has been required for certain government tax incentives and even in some cases the ability to operate a system at all. While still rather intensive, it is far less so than DIACAP. Realistically, looking back on it, it didn’t go into nearly enough depth on security, being focused on healthcare and data integrity.

This doesn’t even touch on the clinical side of things – the actual data directly gathered by medical devices like MRIs, CT scans, x-rays, etc. Most security audits avoid dealing with clinical data directly – it’s a hassle to allow auditors to know anything about those systems, and the auditors seldom have any idea what they’re looking at anyway. Frequently the data is handled in a proprietary fashion which may or may not be well-documented, and frankly it’s often little short of a miracle that it works at all. As a result, even if a hospital or doctor’s office has a secure computer system, the clinical data, the most revealing data, may be the least secure.

The most worrisome part, having been on both sides of the table for security reviews, is knowing that too often they’re looked upon as just another tedious piece of paperwork. As a tech writer, my job was frequently “write something so these people go away”. I’ve also seen security auditors who felt that their job was “find a reason to fail these people”. These attitudes are, of course, common to all security audits. But they become especially worrisome when it’s medical records on the line.

The “attack” (if you can really call it that), required a logged in user to simply modify the URL of an authenticated session to change a plaintext URL parameter containing their account number to another account number. That was all that was required – no coding, phishing, social engineering or other technique that requires any thought was needed. Anyone with a rudimentary understanding of how URL parameters work could have figured this out. I’m amazed nobody figured it out sooner.

What bothers me about the article, though, is that the “expert” and law enforcement representatives who are quoted make it sound like this was a sophisticated intrusion.

One expert, who is part of the investigation and wants to remain anonymous because the inquiry is at an early stage, told The New York Times he wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser.
He said: ‘It would have been hard to prepare for this type of vulnerability.’
…
Law enforcement officials said the expertise behind the attack was a ‘sign of what is likely to be a wave of more and more sophisticated breaches’ by high-tech thieves.

(Emphasis added)

Nothing about changing a plaintext URL parameter requires expertise, and it would have been trivial to prepare for that kind of vulnerability. It’s nigh unbelievable that a financial institution would have such a bad security implementation, although if this is the state of expertise in this field, I suppose I shouldn’t be as surprised as I am.

The adapter essentially acts as a proxy between your computer and a USB drive, meaning it needs no software, has no operating system requirement, and works with everything from a flash memory stick to an external hard drive. All communication with the USB device is encrypted on the fly using 256-bit AES via a certified FIPS 140-2 Level 3 crypto module, but the key isn’t stored on the drive: at the front of the hiddn adapter is a smart card slot.

When you insert a smart card, you have to enter the corresponding PIN code to use it. (After three unsuccessful attempts, the card becomes locked until a longer PUK code is given.) The device does not appear as an active USB device in the OS until a card is verified, and becomes “unplugged” when the card is removed. The encryption key (or half of it in split-key mode) stays on the smart card, making an encrypted drive unusable without it.

Setting up and operating the hiddn system is very straightforward. You connect it to your computer with a USB cable, plug a drive into the top USB port, insert your smart card, and then enter your PIN. From there, the experience is no different than using a USB drive normally – there’s not even a difference in speed.

When I first connected an unencrypted drive on a Windows machine, it appeared as an unformatted drive. After formatting, it behaved just as it would when plugged in directly. (A few times I had to reconnect the adapter to get Windows to recognize a new drive if I didn’t “eject” the drive first or tried a bad PIN, but those were minor issues.) Trying to use the drive without the hiddn adapter after it had been encrypted brought up another prompt to format – Windows could tell there was a volume, but it was completely unreadable.

After using the hiddn Crypto Adapter for a short time, I started wondering why no one else had thought of it before – or at least why I’d never heard of it before. It’s a great tool for anyone wanting a no-hassle method to encrypt removable storage. The only potential drawback is pricing; two adapters and two sets of pre-configured smart cards can run almost $900. High Density Devices offers a few different packages of units and cards, ranging from one of each to ten, as well as an enterprise key management system for creating new cards. But while some users may find hiddn too expensive for personal use, its flexibility, ease-of-use, and high security make for a combination that’s hard to beat.