YubiKey Static Password Mode

Tags

configuration, Guide, Static Password, YubiKey

At least one reader is having problems getting started with the YubiKey, partly because it doesn’t come with instructions. If an operating system doesn’t support using the YubiKey as a 2FA device, there is a way around this – here I’ll show the process for storing a password on the YubiKey, so it dumps the password into a text field when the button on the device is pressed.

To get started, the YubiKey Personalization Tool is needed. Installation on a Linux system was covered here before. When the application is started, there’ll be a list in the main panel and along the top containing the following:

• Yubico OTP
• OATH-HOTP
• Static Password
• Challenge-Response
• Update Settings

The option to select here is ‘Static Password’. The application might then display the following options:

As I want to configure just the one device, I’ve selected ‘Scan Code’.

Static Password Configuration Screen
The YubiKey has two storage regions called ‘Configuration Slots’, either or both of which might contain a password. Before setting a password here, ensure that Configuration Slot 1 or Configuration Slot 2 is checked.

Just below that is ‘Configuration Protection’, which prevents accidental overwrites of the stored configuration. Here I’ve left it as the default, which is unprotected.

Under the ‘Password’ section there are two input fields, which are both disabled/grayed-out. To enable these, a keyboard layout must be selected.

While it’s possible to configure the YubiKey to store and dump passwords, it’s possible to have a two-factor autentication setup by using the Static Password mode to store a prefix. For example, you might set the passwords on your laptop and email accounts as ‘xyz123abc’ + [unique password], and have the YubiKey enter just the first string.

All that remains after entering the password is to click the ‘Write Configuration’ button to write the password to Slot 1.

YubiKey Personalization Tool Settings Tab
One other thing that should be mentioned, just in case the operating system is having problems detecting the YubiKey is the options in the Settings tab.

Serial number visibility determines how the operating system would read the device’s serial number, which is done by reading the hardware descriptor or by reading the API call response. Output speed throttling might also be useful, especially if using the device with an older system that has a much lower input device reading rate.

Using the Programmed YubiKey
Now to use the YubiKey to enter the password in the login screen. Short press of the ‘y’ button on the device to dump the password in Slot 1, and hold the ‘y’ key for longer to dump the password in Slot 2.

A Short Guide to Going Dark on the Move (Part II)

Tags

android, openvpn, vpn

OpenVPN is a flexible VPN client that tunnels network traffic between the local system and a proxy/gateway server, so that nobody between those two endpoints should be able to determine the metadata or the content of your communications. While there are multiple posts on the UWN Thesis blog that deals with setting up OpenVPN on Windows and Linux, I’ve recently managed to get it working again on an Android device.
Of course, you’d need to find a VPN service that appears sufficiently trustworthy, and it’s important to check the session being tunnelled hasn’t been compromised (check the TLS/SSL certificate) once the VPN connection’s established. Remember that service providers are subject to the laws and constraints of whichever countries they’re operating in, and might be required to provide information about their users to The Powers That Be. The best you can do is read the terms of service and privacy statements very carefully.

The application I installed was OpenVPN Connect, which is available in the Play store. After installation, there are a few configuration options to look at.

• Seamless Tunnel: Defintely check this option. The last thing we’d want is the browser to fallback to the default network interface, exposing sensitive data, without us knowing if the VPN service drops the connection.
• Reconnect on reboot: Disabled this, just to be polite and reduce demand on the VPN servers.
• Connection Timeout: Sometimes it takes a while to establish a connection, so this is set to 1 minute.
• Force AES-CBC: Depends. AES-CBC could be better or worse than what’s being provided.
• Minimum TLS: Could set the latest as default, but shouldn’t matter so much.
• DNS Fallback: Even if you dislike Google, this is only a fallback option, and there’s no way to set an alternative.

Once the client configuration is sorted, the connection settings for a VPN service are required. For this demo I’ll fetch and load a connection profile for a service called ‘VPNBook’, which is distributed as a .zip archive of .ovpn files. I have downloaded and extracted these on my mobile device.

In the OpenVPN Connect menu, select ‘Import‘ and ‘Import Profile from SD Card‘. Next find and select the .ovpn file that contains the desired connection settings. Since TCP over 443 seems to work best for my Android device, I’ve loaded the tcp443.ovpn file.

Next you’ll need to enter the username and password, again available on VPNBook’s site. Now the client should establish a tunnel connection.

Once the ‘OpenVPN: Connected‘ message is displayed, I normally navigate the browser to InfoSniper or whatismyipaddress.com, just to ascertain that the browser traffic’s going through one of the VPN servers.

A Short Guide to Going Dark on the Move (Part I)

Tags

android, darknet, firefox, onion, Orbot, tor

I’m probably going to repeating things I posted for the Tor on Linux setup, but I think the Android version of the Tor client deserves a post of its own. The setup I’m using has Firefox (the browser) and Orbot (Tor client and local proxy) installed separately, but it’s possible to install Orfox, which combines the browser and client.

I don’t make any guarantees about the safety here, for obvious reasons – developers are humans, and humans make mistakes when developing software, and few of us have the discipline to be consistent with our OPSEC and tradecraft – Tor on its own masks only IP addresses and I haven’t found a Privoxy equivalent for Android that strips identifying information from the browser traffic payload. You might need to analyse the traffic with Wireshark and work around that.

After launching Orbot, enable the ‘Apps VPN Mode‘, and check the boxes for applications you want routing their traffic through Tor. For example, if you want browser traffic going through Tor, enable Firefox or Chrome (or both). If you want the Android device to route all its network traffic through Tor, enable all the applications in the list.

Pressing the ‘Browse‘ button should launch Firefox, and if the browser traffic’s being routed through the proxy a success message is displayed.

This is enough to get most people started, to claw back some of that pseudonymity, that separation between our online and real-world identities.

Accessing .onion Sites
What about the Onion, or the ‘Dark Web’ (or whatever ominous name the press is calling it these days)? First you need a directory or list of hidden services with .onion addresses. Save or bookmark https://thehiddenwiki.org, and try the Tor search engines to get started – at least some of the links work, but others are a little temperamental.

The next thing you’d need to do is configure Firefox to use Tor servers to resolve .onion addresses, which is something the conventional DNS won’t do. Installing Orbot seems to configure this automatically, but sets .onion blocking by default to precent users accessing the Darknet accidentally. Enter ‘about:config‘ in the browser’s address field, and set ‘network.dns.blockDotOnion‘ to ‘false‘.

Make a note of that, if there might be a need to undo this change. Links and URLs with the .onion suffix should now be resolved and the hidden services made accessible in Firefox.

Other Configuration Options
Because Tor is a shared service with limited capacity, I think it’s only polite to limit my usage of it, so I’ve disabled ‘Start Orbot on Boot‘ and ‘Allow Background Starts‘.

The ‘Request Root Access‘ and ‘Transparent Proxying‘ options are loosely related. One configures Orbot to run the proxy server with root access if possible, and to control the network interface. The Transparent Proxying option should set the Tor proxy as the default virtual network interface for all network traffic being sent and received across all applications running on the device.

There are a set of options under Relaying that enables users to contribute local resources. There should be very little or no risk associated with running a non-exit relay, so it’s a matter of choice whether you’d want to add your device to the Tor network as a resource.

A Tale of Two Keys

Tags

2FA, authentication, crypto, key, Key Storage Device, KSD, password, Yubico, YubiKey

Browsing through the Crypto Museum site several years ago, around the same time I was researching Hardware Security Modules, I came across the ‘Key Storage Device’ (the KSD-64). Provided as a COMSEC solution by the NSA, the device stored the data required for a Secure Telephone Unit to load internally-stored cryptographic keys – an adversary would need both the STU and the KSD to recover the cryptographic keys.
I don’t think its use was limited to NATO or the STU II/III, though, as the KSD-64 was almost identical to another key that a relative of mine carried in the late-1980s/early-1990s. The version I saw was colour-coded yellow, and I’m speculating it had something to do with an ICL VME mainframe, perhaps for stream encryption over a serial line between a terminal and controller. If I can get literature on this, it would make an interesting subject for a separate blog post.

(Crypto Museum, 2010)

Whereas the Key Storage Device’s real advantage was portability and easier distribution of cryptographic keys, it doesn’t provide the same level of security we have in Hardware Security Modules and Smart Cards. The main design differences, in order to provide that level of security are: a) Access to the data storage must be mediated by a processor or controller, and b) The hardware casing must be highly tamper-resistant.

The YubiKey
The reason I brought up this little bit of trivia is I’ve been experimenting with a YubiKey 4 that arrived in the post yesterday. In most configurations it performs roughly the same purpose as the KSD, where is would mimic a keyboard device and dump a password or code into a selected input field when the ‘y‘ button is pressed. It could also be configured to function in a very similar way to a SecurID token. Also it can be implemented as a 2FA device, where one section of a password is entered manually and another section dumped by the YubiKey.

Considering the device costed £40, the packaging is a little basic, but it’s handy if you want to carry the YubiKey in a wallet.

Configuring the YubiKey (Windows and Linux)
For setup and configuration we need to run the YubiKey Personalization Tool, which is a freely-available application.

The Windows application is easy enough to download and run. The Linux version must be downloaded as a .tar.gz source archive, but I managed to compile this within a few minutes, by first executing the prepare-travis.sh script to fetch the dependencies then running the compiler with:
$qmake && make

The compiled application is generated in the /build/release sub-directory. To run the application from here:
$./yubikey-personalization-gui

When starting the application, the first thing users will notice are the configuration types along the top-level menu. These are:

• Yubico OTP
• OATH-HOTP
• Static Password
• Challenge-Response (HMAC-SHA1)

I’ll try my best to explain these configurations without making a mess of it.

Things You Can Do with Static Password Mode
In this mode, the YubiKey can store a password that is later dumped to a password field when the button is pressed on the device – this is very useful if you’ve got a relatively long master password for something like KeePass, and if shoulder-surfing is a problem.
The YubiKey 4 actually has two configuration ‘slots’, which in this regard means the device can store two passwords. A short press of the button dumps the first password, and a long press dumps the second password. Of course, having two slots means it’s also possible to have two different configurations on the same device, such as a short press to dump a password out, and a long press for OTP/HOTP/HMAC.

Now, I’ve mentioned that a YubiKey in this configuration, much like the KSD, doesn’t have protected storage, so anyone could swipe the device and access to whatever you’re trying to protect. One way around this is to enter simple, easy-to-remember passwords manually and have the YubiKey append those with a more complex string – voila, two-factor authentication, sort of.

OTP Configuration
For those who have used an RSA SecurID token, the One-Time Password (OTP) configuration will be slightly easier to understand. Each time the YubiKey is used to begin a session, a single-use password is generated that is very hard to forge or re-use.
How does the server validate this password, though? Well, my IPv6 Secure Address Generation algorithm is an example of OTP, as a hash value is generated from a string containing the system time and a secret code. This value would always change, yet could still be calculated based on a shared key and the system time. Another example is the SecurID token, which displays a secret number generated mathematically from the system time and a ‘seed value’ – the RSA gateway will also know what the secret code should be. The code might be shared by the server with a device over a separate channel, such as SMS or postal service.
The Yubico OTP works a little like this, as the server uses the YubiKey’s Public Identity, Private Identity and Secret Key as the values for generating a password.

OATH-HOTP Configuration
OATH is also known as ‘Open Authentication’, is a set open standards, and shouldn’t be confused with ‘OAUTH’.
The algorithms used here is HMAC-based OTP, in the form HMAC(sharedSecret, counter). The counter is the ‘seed value’, and in this implemementation it’s incremented each time the token is used.

Here the HMAC combines the secret key with an XORed counter value, and generates a SHA fingerprint from this. The SHA fingerprint is communicated so the counter value and secret key are never sent between the client and server.
The counter value is supposed to increment each time the token is used, so it the server and client should have the same value.

HMAC-SHA
Yubico recommends using this for offline use. This combines the secret key with the message to be authenticated (the message being the response to a challenge), and generates a SHA1 hash fingerprint for this. Here we have the option of using a 512-bit secret key.
For this method of authentication, the server presents a question, and the client (with YubiKey inserted) must provide the correct answer. This could be simple as a password request and response, or it could be more elaborate like a response mapped to a randomly-selected string.

So, how does HMAC work with this? The server could select a random set of bytes or characters, and encrypt it before sending to the client as the challenge. The client uses the password to decrypt the challenge and return the hash fingerprint of the decrypted byte/character set. This would computationally prove that both client and server were using the same secret key, though neither the challenge or secret key were sent as plaintext during the transaction.

Counterpoints to the RFID Implant Snake Oil

Tags

32M, Implant, RFID, Three Square Market, TurnKey Corrections

When I read the opinion piece in The Independent, titled ‘A US company has microchipped its employees – we should welcome this as progress and get involved‘, I noticed so much vagueness and inaccuracy in Ab Banerjee’s evangelism of RFID implants that I just needed to post a counterpoint. He may be a CEO of a software company, but he seems to have weighed in without knowing anything about the technology itself or the risks of applying it in the way he advocates. If you want a more balanced and factual digest on this, I recommend the INFOSEC Institute’s ‘Human-implanted RFID Chips‘.

The first thing to know about the technology is it was originally developed for tagging and tracking objects for inventory control, and the tracking of livestock was an early application. However, the idea of implanting RFID chips into humans isn’t new – it’s said that Professor Kevn Warwick was the first person to receive an implant in 1998, and six years later VeriChip was approved by the FDA in the United States.
An RFID tag serves pretty much the same purpose as a barcode, but provides the ability to scan items in batches instead of individually, and probably much faster also. The security application of RFID is a sort of gray area: it’s useful as a blunt tool for identification and access control to low-security environments, but not advisable for authentication. You wouldn’t, for example, use RFID alone to authorise large payments or log into a corporate network, because not even an implanted tag could provide the same level of assurance as a Chip-and-PIN system, or some other 2FA thing that involves more elaborate hardware that was refined to deal with real-world threats. In fact, I’ve visited government facilities that are protected by several layers of three-factor authentication system.

Admittedly I do have a somewhat less rational dislike of RFID implants, and not just because I find it astonishing that a group of adults could peer-pressure themselves into doing stupid shit like this just to use a ‘micro-market’ freaking vending machine. By the way, it’s actually not the future. One thing I’ve learned from last year’s Microsoft marketing events staff conferences is that things are going the way of biometrics, voice recognition and ‘convergence’. Gradually the smartphone will become the ‘hub’ for everything in our digital lives, even authentication with corporate networks. Ergo, I figure the RFID implant would become just as obsolete as the stand-alone MP3 player.

I can’t help but feel there’s something fundamentally dehumanising about the idea of ‘chipping’ people as if they were livestock, and I don’t feel the ubiquity of such implants could bring anything other than a world of societal consequences. My fears aren’t without some foundation.
Several things stood out immediately when first skimming through Banerjee’s opinion piece: He shows a pattern of viewing people in terms of performance metrics and other quantifiables, and his advocacy of the implants is solely in terms of how people are managed. I also think that his dismissal of our objections as irrational actually masks his inability to address the more humanistic questions. Also, what he’s describing, in his ‘vision’, is a workplace environment that most people would find psychologically unhealthy. The opinion piece was actually more about this than RFID technology.

Limits and Capabilities of RFID Implants
It seems a common misconception, one that Banerjee shares, that RFID chips store subjects’ records. They don’t. Instead they typically store an identification number, which usually refers to a database record – in other words it does the same thing as an RFID chip within an ID card. If you look on SmartCard Focus, an RFID tag ~3-4cm diameter stores ~200 bytes. An Ultralight tag has 64 bytes of ROM. For an implant, the ROM size would be much smaller – the VeriChip (which was easily cloned), according to the INFOSEC Institute article, stored a 16-digit number. The chip I think 32M is implanting into its employees (the ATA5577C) could store a 45-digit identifier.

You’re perhaps now asking why anyone would have a thick needle inserted deep into their right hand, between the dermis and fascia, as a delivery method for an RFID chip, when ID cards are substantially cheaper and technically more suited to what Banerjee was trying to describe? Hell if I know, which is why I’ve put ‘Snake Oil’ in the title of this post. But I’ve already answered his first question, and refuted his dismissal of our concerns as ‘predictably hysterical’, ‘scaremongering’ and ‘puff about nothing’. He states:

‘At the moment this data is stored on companies’ tech systems. But why couldn’t it be stored locally on employee microchips? It would be more accessible, and might even give employees better ownership over the data.’

All three sentences are incorrect. The first is that many (maybe even most) companies nowadays use a third-party service for data storage, and that brings a whole different set of issues related to security and trust – I’m surprised he isn’t already aware of this. Since we’ve established that an employee’s record would still exist in a database and not the RFID chip, it would still be just as inaccessible to the employee and vulnerable to being stolen, misused and falsified, and there’s nothing to suggest an employee could do anything whatsoever about it. Now, that alone isn’t better or worse than where we’re at now, per se, but if people received the implant and multiple databases were tied to it (because people aren’t going to have multiple implants), that would pave the way for data mining, egregious privacy violations and all manner of abuses. A future government could also use this, if politicians jumped in, to control the purchasing and movement of individuals. I played my part in the NO2ID campaign against the National Identity Register many years ago precisely for these reasons.

Banerjee’s answer for this is just wishful thinking:

‘make sure the software the chips are paired up with have strong privacy protections. For example, employees should be able to log into their microchip and control whether the data it holds is public or private. This could even be monitored and regulated by the Government.’

No, you cannot ‘log into’ an RFID chip, for reasons that are obvious to anyone who knows what an RFID chip is, and you cannot control whether the information is private since it exists elsewhere. And who exactly would implement and enforce strong privacy protections? There have been countless data breaches and privacy violations involving systems that should have been highly secure, and I can’t think of a case in which it was followed by someone being properly held to account by the government.

So, the moral of the story is that technology should serve people and improve our quality of life as humans. Don’t blindly embrace a bad idea just because someone tells you it’s ‘the future’.