Confirmation Bias and Search Engines


, , , ,

Getting information about last weekend’s Boston Free Speech rally wasn’t easy.

Google returned pages upon pages of results for corporate media sites repeating the same narrative: That the free speech protest was organised by the ‘far-right’, ‘right-wing’ and ‘phony libertarians’, and that it was countered by anti-fascist counter-protesters. I’d like to know how they arrived at this determination, given the lack of information about the protest or supporting evidence.

That’s when I got curious about what might be found using other search engines. The results weren’t remarkably different, and the tone is pretty much the same. returned search results that were more balanced. It’s worth pointing out the word ‘right’ appears five times prefixed with ‘far-’ and ‘alt-’ in the Google results. There were no occurrences of those words in the first Bing results page.

DuckDuckGo’s results are also quite different to what Google returns. Notice most the links here are for local news reports. The term ‘far right’ is absent, and and the organisers are described only as ‘conservative activists’ here.

The results returned by Yandex were very interesting indeed. Why are the Goldwater Institute, American Torchbearers and Daily Stormer at the top of the results? Is this the go-to search engine for the politically-conservative?

I’m not suggesting the above is evidence that Google, or any of the search engines here for that matter, are intentionally manipulating search results. Each search engine uses an algorithm, and there are various factors that determine what users see.
What I will say, though, is that our ‘filter bubble’ extends to how we seek information, and not just what ‘friends’ and people we ‘follow’ post on social media. Next time you research a story, clear your browsing history, try different search engines and see what comes up.


YubiKey Static Password Mode


, , ,

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
  • 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)


, ,

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, 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)


, , , , ,

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, 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


, , , , , , , ,

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 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:

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

  • Yubico OTP
  • 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.

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.