The Vault 7 Release

Tags

CIA, hacking, malware, Vault 7

A price of having an overgrown surveillance industry and routine violations of the US Constitution the inevitability of classified material being exposed. There are too many former CIA hackers with sins to confess, but I wonder about the motives behind this leak. Certainly last week’s Vault 7 release is voluminous and shows that a comprehensive range of things has been compromised, but surprisingly little has been exposed so far relating to violations of their Constitution. What kind of intelligence service doesn’t develop tools and methods for targeted surveillance?
However, there’s a lot that hasn’t been revealed. Wikileaks’ Twitter post claims it’s less than 1% of the material they might publish. The CIA has close ties to Silicon Valley, a data collection budget over four times that of the NSA’s and a comparable allocation for data analysis. The budget for Computer Network Operations (basically what the Wikileaks material exposes), though, is much smaller. According to the press release, the CIA’s Center for Cyber Intelligence had over 5,000 users. It’s therefore a safe bet the CIA does have its own mass surveillance programmes, and anyone of interest to the CIA could have their devices hacked by the Center for Cyber Intelligence.

The consequences of weaponised malware aren’t only domestic. Weaponised malware set a precedent for state-sponsored malicious hacking, and undermined the moral standing and credibility of the US government. When there is a malicious attack on a given state’s network, there’s no telling who was responsible, now we know the CIA was developing methods of implicating other states. Therefore it becomes ludicrous to blame an adversary without very compelling evidence. For example, could we still be so certain the Russian government was responsible for the alleged hacking of the DNC servers, which I believe was unrelated to the published DNC emails?

Things of interest
* Much of the material under the Operational Support Branch section contains useful literature for developers and hackers. There you’ll find tutorials, product documentation, tips, coding practices, links, etc.

* I found a reference to something called ‘Palantir’ in the docs, which appears to be a reference to a testing tool. This caused a bit of fuss when that name appeared in the Snowden material, as it was assumed to be a reference to the company of that name that sells OSINT software.

* Some material deals with defeating ‘personal security products’ – anti-malware that the average home user would have installed. So far, they seemed to have broken past AVG, F-Secure, Comodo and Bitdefender, usually through DLL injection/hijacking.

Dark Mail

Tags

Dark Mail, DIME, DMAP, DMTP, email, privacy, protocol

What makes the Dark Internet Email Environment project look promising is the Dark Mail Alliance consists of the same principled and highly skilled engineers who brought us PGP/OpenPGP and Silent Circle products.

GPG should be an ideal solution for protecting emails on third-party servers – it’s highly scalable, since each person needs only a private key and access to a list of public keys, it’s extensively documented and it has APIs that enable developers to incorporate GPG into their applications. Breaking GPG is non-trivial, and it would be unrealistic for the authorities to expect its developers could maintain a backdoor in an open source project.
The reality is that few people are using PGP/GPG/OpenPGP, since most of us want everything on demand with minimum effort. We all want to sign into our email accounts, or a service like FaceBook, and have our messages instantly available. Hardly anyone wants to download and configure anything, and is why numerous innovative privacy solutions fail to gain traction. StartMail and DIME are two different approaches to solving this.

My understanding, after reading through the Architecture and Specifications document, is that DIME is fairly close to what an automated GPG solution would provide, alongside a form of onion routing. Overall it’s about ensuring everything sensitive, including email headers, is protected between the sender and recipient.

Development is based around four protocols:
* Dark Mail Transfer Protocol (DMTP)
* Dark Mail Access Protocol (DMAP)
* Signet Data Format
* Message Data Format (D/MIME)

DIME should be deployable without too much work. Speaking to Ars Technica, Levison stated: ‘You update your MTA, you deploy this record into the DNS system, and at the very least all your users get end-to-end encryption where the endpoint is the server… And presumably more and more over time, more of them upgrade their desktop software and you push that encryption down to the desktop.’.

Message Structure
The message structure consists of an ‘envelope’ encapsulating the message body and email headers. Protected information includes the sender and recipient addresses. A layered encryption method allows the mail relays to access only the data they need to forward the messages, and using D/MIME the sender and receiver identities are considered part of the protected content. That is, the sender and receiver addresses are considered part of the payload, and should be encrypted along with the message body, which is something GPG doesn’t do.
This is important because the claim that authorities are inspecting only the ‘metadata’ of our Internet communications is misleading. Email addresses and message headers are actually contained within the payload of the TCP/IP traffic being inspected – the content must be read in order to read the email addresses.

Unlike conventional email, the message headers (including the To and From fields) really are processed as confidential, and instead routing is determined by the Origin and Destination fields (AOR and ADR).

Key Management
Public keys, signatures and other things associated with identities are managed as ‘signets’ – all the cryptographic information required for end-to-end encryption between communicating parties. There are two types of ‘signet’: Organisational signets are mapped to domains and contain keys for things like TLS. User signets, on the other hand, are mapped to individual email addresses, and contain public keys associated with them.

There are three modes: Trustful, Cautious and Paranoid. These specifically relate to whether the client or servers handle key storage and encryption. Users have the option of a) ensuring that only client devices have a usable decryption key, and b) trusting LavaBit to manage their cryptographic keys that apparently are extremely difficult for LavaBit admins themselves to access.

Dark Mail Transfer Protocol (DMTP)
DMTP handles the delivery of encrypted messages, with another protocol, D/MIME should protect the content against interception. Basically the email or message is encapsulated, with headers only revealing enough information for servers to relay the message. In order for the encryption to be implemented, the sender must look up the recipient’s public key(s), which happens through a ‘Signet Resolver’ to find a ‘signet’ that contains the public key.
DMTP is also the transfer protocol for retrieving ‘signets’.

The transport method is actually quite similar to conventional email. It uses an additional field to the domain name records, pointing to the DIME relay server.

One requirement of DMTP is that all sessions must be secured by TLS, and with a specific cipher suite (ECDHE-RSA-AES256-GCM-SHA3841).

Dark Mail Access Protocol (DMAP)
The finer details for this haven’t been established yet, and this section appears to be notes of a few points. DMAP is being designed to handle the key exchange and authentication side of the secure email implementations, making sure the client’s keyring is synched with the ‘signet’ admin servers.
DMAP is to incorporate something called ‘Zero-knowledge password proof’ (ZKPP), a way for two entities to confirm that each knows a secret value without exchanging that value.

Installation of DIME on Mail Servers
A development version of the DIME library can already be installed on a Linux system. Unfortunately I haven’t managed to get this compiled and installed on Linux Mint, even with the dependencies sorted. I’m still working on installing these on a CentOS server.

The dime executable enables the lookup of signet/address mappings, verification of the signets, the changing of DX server hostnames and the reading of DIME management records. The sending and receiving servers are determined using the dmtp tool. Signets, they are generated and managed using signet as .ssr files.

A proof-of-concept program (genmsg) in included for sending Dark Mail messages in the command line. To do this, the sender specifies the sender address, the recipient address and the path to the ed25519 signing key.
Once on the server, the messages are stored in a typical database scheme on a Magma server.

OpenPGP for Windows Phone

Tags

Contacts, encryption, messaging, openpgp, pgp, Phone, windows

A couple of interesting PGP applications are available for Windows Phone, which would be useful if you trust the Windows 10 operating system enough to not to upload your cryptographic keys to Microsoft’s servers. I trust it enough for my secondary, less sensitive, email accounts.
OpenPGP for Windows is used for managing the user’s PGP keys and encrypting/decrypting messages. The companion application, OpenPGP Contacts, is used for fetching and storing the public keys for contacts.

Generating a PGP Key
If you already have a public/private key pair, it can be imported in OpenPGP for Windows. If not, it can be created in this application.

And key parameters:

However, I strongly recommend generating the keys on a physical Linux machine.

Contacts
Previously I have submitted two public keys to keyserver.ubuntu.com, and have added that server in the OpenPGP Contacts settings, which enabled me to store both keys here.

Encrypt Message
The application has a basic text editor in which to type messages. Whatever is contained here is converted to ciphertext that’s copied to whichever messaging application.

Pressing the ‘+’ button in the ‘To‘ field will display the public keys stored by OpenPGP Contacts, and the text entered here will be encrypted using that key. The encrypted message can be shared with other messaging applications on the device, to send it as an email or text message.

Decrypt Message
To decrypt, simply copy and paste from the messaging application to OpenPGP application, and select the private key for the decryption.

PGP Message Encryption for Web Mail (Part II)

Tags

email, encryption, GMX, Mailvelope, webmail

Halfway through doing my last blog post on PGP, this Web mail pop-up caught my interest:

Mailvelope is a browser extension which ‘brings OpenPGP encryption to webmail services such as Gmail, Yahoo and others’. Does it provide any advantage over the other method of encrypting text files? Well, kind of. Mailvelope stores PGP keys locally and converts a plaintext message into ciphertext without the user having to leave the browser – that alone is a major improvement on usability. I had a few problems with the setup, as the recovery key for GMX’s encryption didn’t export properly to PDF (basically I’ve lost it).

Mailvelope’s FAQ page states that keys are only stored locally, and explains that security depends on the endpoints being resistant to attack. It is transparent about the extension scanning all Web pages to determine whether it’s a Webmail service being displayed.
What’s less obvious is the correct procedure must be followed when composing emails in order for Mailvelope to provide confidentiality. Web mail services (especially Google) typically save messages as you type, which means the plaintext is stored on their servers, and that makes pretty much the entire conversation accessible to third parties. This means you absolutely must compose emails in Mailvelope’s pop-up editor instead of the Web mail interface. We’ll come to this.

Creating or Importing Keys
Since I already have generated keys for my Web mail accounts, I’ll import them here. The way to import a key from a file in the Import Keys page is to open whatever private key in a text editor, and copy it into the ‘Import key as text‘ box. The public key will be derived from this.

The key can be managed and the public key uploaded to Mailvelope’s server. Because the verification email needs to be decrypted using another program, and the plaintext link is malformed, I submitted my public keys to the Ubuntu key server instead.

Back to Web Mail
According to the setup dialogues, GMX doesn’t have access to the crypto key. When setting this up, do not lose the recovery key, as the encryption cannot be reset without contacting GMX’s technical support team.

Mailvelope also works with Outlook, displaying a small pad icon in the top-right of the content box. Click that icon before doing anything else.

The following window should then be displayed:

Compose the email in the following window and click the ‘Encrypt‘ button.

PGP Message Encryption for Web Mail in Windows (Part I)

Tags

Ciphertext, encryption, gpg, Kleopatra, message, openpgp, windows

Since PGP/OpenPGP can decrypt the contents of files, generating ciphertext from plaintext, there is a workaround for anyone using Web mail that doesn’t support PGP or email clients with that feature. A full version of Gpg4win includes the core GPG components and the Kleopatra interface.

With this installed, the next step is to create a public/private key pair. To generate a key pair, launch Kleopatra, and select ‘File – New Certificate…‘.

The advanced settings allow for the selection of different key sizes. 2048 bits should be considered the minimum key length for a reasonable level security. A 4096-bit key wouldn’t provide much extra benefit, unless you were generating the keys on a hardened Linux machine and storing them on a Smart Card or security module. The point is a private key should be stored the same way a text file containing passwords would.

To export the public key, right-click the certificate entry and select ‘Export Certificates…‘. To export the private key, ‘Export Secret Keys…‘. The public key is the one you’d publish or share, and the private key is the one you don’t share with anyone. For the purpose of this demo, I have exported both to a folder in MyDocuments.

Encrypting a Message
Type the message as normal, and save to a local directory as a standard text file.

Next, navigate to the directory, right-click the file and select ‘Sign and encrypt‘. Here you can select ‘Encrypt‘ (without signing), and check the ‘Text output (ASCII armor)‘ to generate ciphertext that can be copied into a Web mail interface. The ciphertext is saved as an .asc file.

Decrypting a Message
The reverse process is used for decrypting a message. Save the ciphertext to a local directory as a text file. This time, right-click the file and select ‘Decrypt and verify‘.

Kleopatra should automatically select the relevant private key, if it’s present, and prompt for the password.