Monthly Archives: January 2011

MintyBoost XL: Almost Finished!

Well, I finally drilled my PCB for my MintyBoost XL last night, and it was a great success. If you need PCB drill bits, order them from stevie66 on ebay. I got various sizes from 50 to 85, but I found the 65 to be the most useful. I used it to drill all but the largest holes on the board.

Flickr Tag Error: Call to display photo '5394561101' failed.

Error state follows:

  • stat: fail
  • code: 95
  • message: SSL is required

Once that was done, I soldered it all together. It came out very nicely. I struggled the most with the mint tin!

Flickr Tag Error: Call to display photo '5395156442' failed.

Error state follows:

  • stat: fail
  • code: 95
  • message: SSL is required

I hooked it up and tested the input: about 2.3v. Then, I carefully tested the USB output power pins: 5.03V! This thing works beautifully.

Flickr Tag Error: Call to display photo '5395157098' failed.

Error state follows:

  • stat: fail
  • code: 95
  • message: SSL is required

I found an issue with my implementation of this project, though. The LT1303 IC doesn’t support current above 200mA, so my phone rejects the charge after about 5 seconds. I found out you can request samples directly from Linear, so I’ll be trying out a 1302, and perhaps redesigning the board to use a newer generation chip I’m sampling from Linear Technology.

Overall, this is great for the intermediate electronics nerd who wants to take a circuit from board layout in Eagle to working semi-professional product! I had a lot of fun doing it, and making small modifications will be even more fun.

The Government’s Certificate Authority: Why you shouldn’t worry

Well, yesterday, I made a nice long response to a blogger I follow who was confused and upset over this idea to have the government as a TLS client certificate authority, much like Thawte or CACert, but with its own system of identity verification. He apparently refused to post the comment, and instead opted to post comments from other people who don’t understand how the public-key infrastructure works. Here are the gems of intellect:

This angers me, and it seems like ever since he started working for FOX News, almost all his posts are hugely politically motivated, and most of the discussion about gun rights, which I enjoyed, has deteriorated into weekly updates on successful gun usage. While this is a bit interesting, it’s not worth reading all the ignorance, and having your completely well-reasoned responses ignored. I think I’ll be unsubscribing.

Just the facts, ma’am.

The article specifically states/quotes the following:

There’s no chance that “a centralized database will emerge,” and “we need the private sector to lead the implementation of this,” he said.

So, that being true, it will probably be handled the correct way, which is something I’ve been waiting for. If this were not mentioned, I would be concerned that a central database would be necessary. Even if that were true, only people without social security numbers should be concerned, as that is already a central database with tons of vital information about you.

How is this going to work?

I assume they are planning to create a certificate authority which will sign certificates generated for people by the private sector or individuals. What this means is that you, the citizen, can generate a public key and a private key (a key-pair) for use in encryption and digital signatures. You can then submit a certificate signing request to the government, who can use their private key, guarded behind lock and key, to sign the certificate without ever having seen it. Because of this, they still have no ability to decrypt any document encrypted with your public key. You can keep your private key on a computer that doesn’t have any ability to connect to the internet and use sneakernet to encrypt and sign documents if you like. Most people just resort to symmetric encryption of the private key (password protection) instead, since this is easier practically, but a bit less secure as most people’s passwords aren’t the greatest. If you want a good password, see my post here – and don’t use the first command, use the crazy perl one.

This is how server certificates currently work on the internet. Say you’re a bank, and you need to have SSL work for your customers. You create a TLS key-pair, make a CSR (certificate signing request), ship that off to any of about 40 different companies/authorities for identity verification and usually payment (see CACert for an alternative to payment), and eventually receive a signature for your key from that company.

Most browsers have these 40 or so certificate authorities (to use their correct name) embedded in their guts, so whenever a public key is encountered when making a secure connection, your browser can verify its signature to test its authenticity. What this means is that your security is currently in the hands of these 40 or so companies/authorities (Verisign, the Chinese government, the US government, etc. – a full list is here). If someone’s malicious site obtains a signed certificate from just one of them, your browser will have little closed locks and green colors all over it, saying it’s 100% secure. For those who are less technically inclined, this is a bit confusing – even though the connection is secure, your personal information is not.

Anyway, with personal certificates, the validation and signing process is essentially the same. The metadata attached to the certificate might have some of your vital information (social security number?) since that would be required to validate the certificate at the government’s CA. Let’s say I obtained one of these government-signed certificates – what would that mean? Well, it would mean I would be able to use it on any site that trusts the government! If your site doesn’t trust the government, you don’t have to recognize them as a signing authority – it’s that simple. Of course, that might limit your audience a bit, since they’ll have to authenticate some other way. Also, if the social security number is included in the metadata for the public key, I have a feeling most people won’t be using it in daily browsing because of security concerns, and rightfully so. Where this makes sense is any official interaction with the government that occurs online – things like doing your taxes. Imagine, you have one of these certificates, and so does your tax preparer if you use one. Both of you can sign the digital document that contains your taxes, and submit it to the government. This is much more authoritative that a signature in ink (I mean, seriously, that is the worst form of authentication). The government can mathematically prove that your key was used to sign it, meaning either someone figured out how to steal your key or you actually did the deed. This brings up another interesting point.

What if my key is compromised?

The government, as a certificate authority, would have to maintain a revocation list. This is a list of certificates signed by that authority that are invalid for some reason. Maybe they were compromised like I suggested above, maybe by using a bad password on the private key. Then, anyone needs to be able to obtain an updated copy of this list from the certificate authority.

Why is this better than a social security number?

The real win here is hidden under the surface. If this is implemented, one’s parents could generate them a key-pair at birth, have it signed, and that person’s “social security number” is just the hash value of that public key, which is a completely public number! If it needs to be verified, fine! The person just signs whatever document needs to be verified with a key-pair that matches that hash! It’s like if your social security number had a piece that was never visible to the public, but could verify your authenticity as a citizen. Applying for credit-based accounts would be ridiculously easy if you used your certificate to verify your authenticity. Got phone calls about debt collection and they don’t believe you’re who you say you are? Just sign a document they provide and send it back to them. That should be a lot easier than arguing over the phone. The possibilities are numerous. Actually, buying a gun might even be easier since most of the forms could be completed online in one’s home by clicking and typing rather than sitting in a dealer’s shop in person for an hour. Just load up your private key, which fills out all your vital information for you, click some radio buttons, submit to the state police, receive a signed (!!!) response, forward it to your gun dealer, go pick up your gun. It’s so easy, and the PKI (public-key infrastructure) makes it possible.

Also, there should be no limit to the complexity of the keys other than generation time. If you want a super secure key, use a natural source of entropy for a long period of time, and create something very very large. Right now, the standard secure personal key seems to be 2048-bit, but 4096-bit is quickly becoming the new standard. Soon, 8192-bit will be the thing to have, and so on. Since these hypothetical USKeys (I just made that up – it totally should be called that) need to be extremely secure, software may have to be updated to accommodate their size. Were they to be created today, at least 8192 of not 16384 bits should be used to make them last at least 20 years (barring huge advancements in public key encryption attacks).

Sadly, there is a possible issue with this system. Quantum computing might pose a threat to some of the algorithms currently used for public-key infrastructure. Luckily, the math world is beginning to bring us answers. Regardless of the implementation, the high-level idea is still the same – users generate a key of some sort, authorities sign a piece of it, users submit that signed piece to places, identities are verified, information is encrypted, everything is happy.

In summary, I really think that this could change a lot of the non-secure protocols in the government’s operation, and almost definitely the operation of many businesses that depend on valid identities. I just hope they don’t screw it all up, which knowing the government, they very well could.

Making my own PCBs

I’ve always wanted to make my own PCB, so today is a special day for me.

This is for the MintyBoost XL, which is totally awesome. Now I just have to etch it, drill it, and solder all these little components onto it…

I used the instructions found here to create this little gem. They are very good, but I modified the method slightly. Instead of taping crap down, you just heat up the board like he says, carefully stick the paper to it toner side down, and start ironing for a few minutes, pushing hard and using the tip of the iron to go over every everything nice and hard. Also, cleaning is key – I used some 220 grit sandpaper and then acetone with a paper towel, and it turned out great.

The schematic is available here. All credit really goes to Robert Hunt though – it’s his design. Also, here’s my slightly modified parts list I ordered from Digikey for this project:

2 490-5401-ND CAP CER 0.1UF 50V Y5V RAD

Total parts cost: $11.87.

Not too bad for a little DIY and fun. Board cost a few pennies.


I got tired of waiting for my FeCl in the mail, so I used some awesome instructions to take Muriatic Acid (also known as Hydrochloric Acid) from Lowes and Hyrdrogen Peroxide and mix ’em together with the PCB to etch it, and also yield a byproduct of Cupric Chloride, which is also a reusable etchant itself! And it did a fantastic job:

I made sure to find plastic containers that don’t react or melt when exposed to the acid – my tray was from Walmart and is PVC and my container for the leftover acid was an HDPE milk jug. So far, so good!