If you haven’t heard of the service you can find out more here – Google Wallet (Wikipedia).

The main concern here (security wise) is that this relies on a secure storage on the phone of your cryptographic keys that allow you to carry out transactions.

Sprint’s two newly announced 4G handsets both support Google Wallet, bringing an important boost to Google’s aspirations, but they also hammer the death nail into WiMAX in the USA.

Sprint’s last 4G handset, the “Sprint Nexus S 4G”, was a WiMAX device, but Sprint has admitted backing the wrong 4G horse and is now transitioning to LTE across its network. So the operator will now be selling Google’s Galaxy Nexus and LG’s Viper handsets, both with support for Google Wallet for those wanting pay-by-bonk functionality.

Supporting the ability to make payments by tapping the phone against a reader isn’t just a matter of supporting Near Field Communications (NFC), you also need a secure element in which to store the cryptographic keys, which will be under the control of a mutually-trusted party, and then an application with which to make the payments.

Both the Galaxy Nexus and the Viper have a module built into the phone, under the control of Google – which is trusted by Mastercard and Visa. So far only Google itself and Citibank have created applications with which a user can make payments, and despite offering to pay for users’ groceries, Google Wallet is proving something of a slow burner at best.

I’d imagine the wallet system will have functionality to auto-reload from your credit card too, so if someone can manage to grab those cryptographic keys from the ‘secure’ area on your phone – you might be in for a surprise when you get your next credit card statement.

The plus side is, the adoption rate so far seems to be super low – so it’s not much of a risk right now.

It has not been helped by Verizon asking to have the functionality disabled in its spin of the Galaxy Nexus. The operator claims the decision was down to integration issues, but it is widely believed to have made the call in order to hold back a competitor until the US-operator-consortium wallet, ISIS, comes online.

ISIS uses a secure element held in the SIM – and thus under the operators’ control – and should work with any handset supporting the SWP (Single Wire Protocol) standard for NFC/SIM communications.

So once ISIS is available then the operators will start pushing it out to everyone with an SWP-supporting handset, including the Google Galaxy Nexus and LG Viper. Google needs to move fast and grab some market share before the operators shut it out, which is why these new handsets are so important to the Chocolate Factory as well as to Sprint.

There’s a whole lot of politics going on too with a new mobile payment system set to come online soon – ISIS – founded by…wait for it…AT&T, T-Mobile and Verizon. Yah, screw whoever tries to mess with ISIS – because they are gonna be in big trouble – the only major US operator missing is Sprint.

I’m guessing that’s why they are going with Google Wallet, there’s a very short article on Wikipedia about ISIS here.

Source: The Register

I can’t see any real corporate use for Twitter, so they won’t be pushing the security aspects of it in terms of the application. Perhaps it’s just an equity play and has nothing to do with Twitter, or perhaps they have another offering up their sleeves which isn’t public yet.

Twitter may be planning to boost its mobile security options with the acquisition of Whisper Systems, a company that offers security products for Android phones.

Whisper Systems’ offerings include WhisperCore, software that enables full disk encryption as well as management tools for Android phones. It’s free for individual users while enterprise customers pay for the software. Other Whisper Systems products include text encryption, voice encryption, firewall software and encrypted backup.

In a blog post about the acquisition, Whisper Systems didn’t say much about what Twitter might be planning to do with the technology. “Now that we’re joining Twitter, we’re looking forward to bringing our technology and our expertise into Twitter’s products and services,” the company wrote on the blog.

It said that Whisper Systems software will continue to be available but that during a transition period the company will take the products and services offline. In a forum on Whisper Systems’ website, people who are apparently unaware of the acquisition are already wondering why they can’t download products. Twitter did not reply to a request for comment about its plans for the technologies.

The only path I can see, obvious path that is, would be for Twitter to integrate the encryption technology offered by WhisperCore into the official Twitter apps – making them more secure in both storing data locally and in transmitting data over insecure networks.

I don’t see how it really offers any value though, it’s not like anyone is actually sending anything important out over Twitter – apart from the odd DM (Direct Message) I would imagine.

It’ll be interesting to see what direction they take though and if we can actually find out why this acquisition took place.

WhisperCore has a number of features designed to make up for security shortcomings in Android. For instance, WhisperCore users can selectively revoke permissions that an app requests while allowing the user to still use the app.

The software also includes a feature aimed at thwarting someone who has stolen a phone from determining the phone’s unlock code based on finger smudges on the screen. Some Android phones display rows of dots and a user unlocks the phone by dragging a finger over certain dots in a set pattern. An attacker might be able to recreate the pattern by examining finger smudges on the screen. WhisperCore displays unlock numbers in a column, so an attacker doesn’t know in which order the user hits the numbers to unlock the phone.

Earlier this year Whisper Systems released a software development kit so that developers could start building some WhisperCore features into their applications.

Few other companies are doing full disk encryption for Android, although there are many other companies taking other approaches to securing Android phones. Companies like 3LM and Good Technology offer mobile security services for enterprises. In addition, mobile device management products from companies including Sybase, BoxTone, Zenprise, Mobile Iron and Fiberlink let IT managers set basic policies like password requirement and remote wipe, and offer additional security capabilities.

The other whacky idea could be to make Twitter into a dual-functioning security product – I don’t really see how that would work though. Social Networking + Device security = confused users.

If anyone has any bright ideas as to why you think this deal took place, do drop them in the comments section below.

Source: Network World

Or perhaps some of you already use something totally web-based like Hushmail, the story is that researchers in Germany have managed to develop a JavaScript implementation of OpenPGP that allows you to both encrypt and decrypt messages purely in the webmail interface with Google Chrome and Gmail.

Pretty neat eh?

Researchers from German security firm Recurity Labs have released a JavaScript implementation of the OpenPGP specification that allows users to encrypt and decrypt webmail messages.

Called GPG4Browsers, the tool functions as an extension for Google Chrome and now is capable of working with Gmail.

According to its developers, GPG4Browsers is a prototype, but it supports almost all asymmetric and symmetric ciphers and hash functions specified in the OpenPGP standard.

The OpenPGP specification uses public key cryptography to encrypt and digitally sign messages and other data. It is based on the original PGP (Pretty Good Privacy) program and is most commonly used for securing email communications.

Setting up a PGP variant to work with a particular email client on a local computer can prove troublesome for less technical users, not to mention that it’s not portable. A PGP user who wants to send and receive encrypted emails from a different computer, would have to install it on that system first, import his private and public keys into the local database, known as the keyring, and then configure his email client.

The benefits of a JavaScript-based implementation that runs inside the browser is that it doesn’t require a dedicated email client or other software installed on the computer.

I have to admit, setting up key based e-mail cryptography to work seamlessly…is not for the faint of heart. Even for the more technical user, it can be quite a pain in the arse.

That’s a pretty high entry barrier for the average Joe and stops pretty much everyone else from encrypting their emails. Something more seamless (and totally portable) like this JavaScript implementation could open up key-based e-mail encryption for the masses.

At the moment, GPG4Browsers only works in Google Chrome and is not available for download from the Chrome Web Store. However, if the name is any indication, the extension will be ported to other browsers in the future.

Users interested in giving it a try must download it manually and install it as an unpacked extension. This can be done from the Tools > Extension page by checking the “Developer mode” box and clicking on “Load unpacked extension.”

The current release is limited by the fact that it cannot generate private keys, although the menu for doing this is present, so the feature will most likely be implemented in the future.

Importing public and private keys works fine and when browsing on Gmail a black lock icon is displayed in the address bar. Clicking on it will open a dialog for composing an encrypted or a digitally signed message.

Similarly, when an encrypted message arrives in the Gmail inbox, the browser asks users if they want to open it with GPG4Browsers. The extension can decrypt messages signed with GnuPG (GNU Privacy Guard), a popular open source PGP implementation, but only if data compression isn’t used.

The GPG4Browsers source code is available under a GNU Lesser Public License so the tool can be easily improved to support additional webmail providers. The developers also provide documentation which explains the available APIs.

An OpenPGP JavaScript implementation offers convenience and portability, but also has some downfalls. “Since memory-wipe of private data and validation of a secure execution environment cannot be achieved in JavaScript this implementation should not be used in environments where the confidentiality and integrity of the transmitted data is important,” the developers warned.

Which means, in basic terms, don’t use this kind of implementation on any machines that might be infected with malware etc. Which in a way to me renders it useless, the only reason I’d be using a web-based OpenPGP implementation is because I’m using a public or unfamiliar machine and I STILL want to encrypt my e-mail.

If I’m using my own e-mail, I’ll be using a proper software based encryption tool anyway. So I guess it may offer slightly more protection that sending completely plain text e-mail, but it’s certainly not a totally secure e-mail encryption solution.

As JavaScript progresses and gets more powerful however, things may change and this may well become a viable alternative to software based e-mail encryption.

Source: Network World

Perhaps that incident and spate of attacks and intrusions had something to do with this most recent story, the story of a stolen certificate.

The story is that a ‘missing’ certificate which has been legitimately signed by the Malaysian government was stolen and has been used to sign malware, enabling it to bypass OS protection which prevents the installation of untrusted applications.

Researchers have discovered malware circulating in the wild that uses a private signing certificate belonging to the Malaysian government to bypass warnings many operating systems and security software display when end users attempt to run untrusted applications.

The stolen certificate belongs to the Malaysian Agricultural Research and Development Institute, according to Mikko Hypponen, chief research officer of F-Secure, the Finnish security firm that found it was being used to sign malware spread using booby-trapped PDF files. By using the official credential to vouch for the trustworthiness of the malicious application, the attackers were able to suppress warnings Microsoft Windows issues when users attempt to install unsigned applications.

“The malware itself has been spread via malicious PDF files that drop it after exploiting Adobe Reader 8,” Hypponen wrote in a blog post published on Monday. “The malware downloads additional malicious components from a server called worldnewsmagazines.org. Some of those components are also signed, although this time by an entity called www.esuplychain.com.tw.”

The discovery is the latest reminder of the challenges posed in securing the PKI, or public key infrastructure, used to digitally ensure the authenticity and integrity of websites and applications. With more than 600 entities entrusted to issue the certificates, all it takes is the compromise of one of them for an impostor to obtain the private key needed to issue counterfeit credentials for Google, eBay, the Internal Revenue Service or virtually any other service.

The certificate came from the Malaysian Agricultural Research and Development Institute, known locally as MARDI – http://www.mardi.my.

Please also note the fantastic aesthetics of Malaysian government web design, I’d estimate a few million USD was spent to create such a glorious website – it shows doesn’t it.

The security of Malaysian governmental website is also extremely suspect, any half decent attacker seems to be able to hack into them without much effort. Probably because most of them aren’t maintained and they are running outdated, vulnerable versions of the CMS Joomla!.

Over the past couple years, a growing number of private keys have been abused. One of the best known examples was the Stuxnet worm that sabotaged Iran’s nuclear program. It used pilfered digital keys belonging to two companies from Taiwan. The Duqu malware, which some researchers say has significant similarities to Stuxnet, also used private certificates.

Hackers recently compromised the systems of Netherlands-based certificate authority DigiNotar and minted counterfeit credentials for half a dozen sites, including Mozilla’s addons website and Skype. A bogus certificate for Gmail was used to spy on about 300,000 people accessing the service from Iran.

Two weeks ago, credentials issued by intermediate certificate authority Digicert Malaysia were banished from major browsers following revelations the company issued secure sockets layer certificates that could be used to attack people visiting Malaysian government websites. A day later, Netherlands-based KPN Corporate Market said it suspended the issuance of new certificates after discovering a security breach that allowed hackers to store attack tools on one of its servers.

The compromised certificate discovered by F-Secure shows the signer as anjungnet.mardi.gov.my. It expired at the end of September. Hypponen said Malaysian authorities have indicated the certificate was stolen “quite some time ago.”

It just goes to show how weak the whole PKI type infrastructure is, especially with the recent case – Hackers Get Hold Of Wildcard Google SSL Certificate – Could Hijack Gmail Accounts.

Of course before that we had the huge RSA SecurID case too, some quiet hacking, some stolen certificates (which are basically just text files) and bingo – you have yourself some real power there.

Sadly this kind of occurrence seems to be getting more and more common, I hope things get secured because people have been told for years that “If it’s https it’s safe!” – when clearly…that is not always the case.

Source: The Register

This was an interesting find because it wasn’t too long ago I published a post about Mediggo, a Tool To Detect Weak Or Insecure Cryptosystems Using Generic Cryptanalysis Techniques.

Requirements

Windows Binaries included in this distribution as well as supporting libraries were compiled using gcc, Mingw and Msys.

Linux binaries were compiled using gcc 4.1.2. They were tested from command line in machine with Windows Vista Home Premium (32 bit + SP1) and on Linux Gentoo 2008.0 X86 operating systems.

Compiling

Version 1.02 includes standard configuration scripts for Unix like systems. The old Makefile (Makefile.linux32) is still included; if you use Windows I suggest you use MINGW+MSYS.

You can download CIAT v1.02 here:

ciat-1.02.zip

Or read more here.

This library is open source (LGPL licence) and written in C programming language. Samples and test cases are provided with each techniques:

• the solution is not always given to make people practice
• the solution can always be obtained by contacting the development team

Current Features

• Detection and cryptanalysis of weakly implemented or trapped systems

Future Features

• Automatic detection of statistical biases in cryptographic algorithms.
• Specific cryptanalysis tools.

You can download Mediggo here:

megiddo-0.4.0.tar.gz

Or read more here.

With the recent news Lockheed Martin Hacked – Rumoured To Be Linked to RSA SecurID Breach and another US Military sub-contractor compromised through SecurID tokens – RSA have FINALLY come clean about it.

They basically have to replace all 40 million SecurID tokens out there, imagine how much of a headache that is going to be – and how much is it going to cost? This is going to end up as one hell of a costly hack for RSA.

RSA Security is to replace virtually every one of the 40 million SecurID tokens currently in use as a result of the hacking attack the company disclosed back in March. The EMC subsidiary issued a letter to customers acknowledging that SecurID failed to protect defense contractor Lockheed Martin, which last month reported a hack attempt.

SecurID tokens are used in two-factor authentication systems. Each user account is linked to a token, and each token generates a pseudo-random number that changes periodically, typically every 30 or 60 seconds. To log in, the user enters a username, password, and the number shown on their token. The authentication server knows what number a particular token should be showing, and so uses this number to prove that the user is in possession of their token.

The exact sequence of numbers that a token generates is determined by a secret RSA-developed algorthm, and a seed value used to initialize the token. Each token has a different seed, and it’s this seed that is linked to each user account. If the algorithm and seed are disclosed, the token itself becomes worthless; the numbers can be calculated in just the same way that the authentication server calculates them.

What bothers me, from a cryptography stand-point at least, is that RSA should not know or even be able regenerate the seed and associated token value for their clients.

And along side that, surely SecurID is used as a part of a two or three factor authentication system, so what happened to the other factors in these hacks? Why were they so easily compromised once the hackers could generate the token values?

It just amazes me how these security related companies (with military information) can be so lax on security. Even if the token failed – no one should have been able to get in!

This admission puts paid to RSA’s initial claims that the hack would not allow any “direct attack” on SecurID tokens; wholesale replacement of the tokens can only mean that the tokens currently in the wild do not offer the security that they are supposed to. Sources close to RSA tell Ars that the March breach did indeed result in seeds being compromised. The algorithm is already public knowledge.

As a result, SecurID offered no defense against the hackers that broke into RSA in March. For those hackers, SecurID was rendered equivalent to basic password authentication, with all the vulnerability to keyloggers and password reuse that entails.

RSA Security Chairman Art Coviello said that the reason RSA had not disclosed the full extent of the vulnerability because doing so would have revealed to the hackers how to perform further attacks. RSA’s customers might question this reasoning; the Lockheed Martin incident suggests that the RSA hackers knew what to do anyway—failing to properly disclose the true nature of the attack served only to mislead RSA’s customers about the risks they faced.

I’m fairly sure we’re going to hear more about this, and I wouldn’t be surprised if we start seeing some lawsuits from disgruntled clients of RSA popping up. It seems like RSA went the security through obscurity route – rather than responsible disclosure and letting everyone what was going on.

They thought they could protect against hackers…by not saying anything?

Seriously RSA, is that the best you’ve got? The recent compromises of US military contractors proves that that tactic didn’t work at all (unsurprisingly).

Source: ars technica

The latest news linked to the above breach is that Lockheed Martin has been compromised and it could possibly be linked to the SecurID tokens. Now this is a BIG deal as they are a US Military contractor and probably have some pretty juicy secrets in their network.

Lockheed Martin Saturday night acknowledged that it its information systems network had been the target of a “significant and tenacious attack,” but said that its security team detected the intrusion “almost immediately and took aggressive actions to protect all systems and data.”

No data from customers, programs or employees was compromised, the top U.S. defense contractor said in a brief statement.

The company said that it has kept U.S. government agencies informed of its investigation as it “continues to work around the clock to restore employee access to the network.”

The attack was first reported last Thursday by Reuters, which cited a defense official and two unnamed sources familiar with the situation. The news agency reported that the cyberattack was affecting many employees at Lockheed Martin, which is based in Bethesda, Maryland, and makes fighter planes and other weapons systems.

Bruce Schneier mentioned it here – Lockheed Martin Hack Linked to RSA’s SecurID Breach

And a lot of people have been sayings it’s just speculation, yah the hack is real – but does it have anything to do with SecurID really? We have no idea.

There’s some interesting thoughts on it here – Weekly Intelligence Summary:2011-05-27

On Saturday, an official with the U.S. Department of Homeland Security confirmed the attack to the news agency. However, Lockheed Martin continued to decline comment.

The intrusion reported involves the use of RSA SecurID tokens, used by Lockheed Martin employees to access the company network remotely. Security analysts have urged that companies using the tokens review authentication procedures.

Lockheed Martin did not divulge how its systems were attacked. The company faces “constant threats from adversaries around the world” and regularly acts to heighten security of its systems, it said in the statement.

Homeland Security have confirmed the compromise but as of now, Lockheed Martin has no made statement regarding what has happened or what data has been accessed.

There some thoughts from SANS ISC Diary here on how to stay secure even if you do use SecurID – Lockheed Martin and RSA Tokens.

It’ll be interesting to see what other news comes out about this and if any actual details are revealed. We shall be keeping an eye on it.

Source: Network World

Google researchers claim they’ve devised a way to reduce that painful wait when visiting an SSL encrypted site. Now, it may be faster but is it any less secure? You’d have to run through the paper to ascertain that.

And well it can only work in a few very specific sets of circumstances, it’s not like it’s really going to change anything on a large scale.

Google researchers say they’ve devised a way to significantly reduce the time it takes websites to establish encrypted connections with end-user browsers, a breakthrough that could make it less painful for many services to offer the security feature.

What’s more, the technique known as False Start requires that only simple changes be made to a user’s browser and appears to work with 99 percent of active sites that offer SSL, or secure sockets layer, protection.

“We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times,” Google software engineer Mike Belshe wrote in a blog post published Wednesday. “SSL False Start reduces the latency of a SSL handshake by 30%. That is a big number.”

The finding should come as welcome news to those concerned about online privacy. With the notable exceptions of Twitter, Facebook, and a handful of Google services, many websites send the vast majority of traffic over unencrypted channels, making it easy for governments, administrators, and Wi-Fi hotspot providers to snoop or even modify potentially sensitive communications while in transit. Companies such as eBay have said it’s too costly to offer always-on encryption.

The Firesheep extension introduced last year for the Firefox browser drove home just how menacing the risk of unencrypted websites can be.

There’s a blog post about the speed improvements here:

SSL FalseStart Performance Results

It shows an approximate 30% reduction in the overall SSL connection setup time. They say they have implemented it in Chrome 9 (the current public release of Chrome is version 11) – so that makes me wonder has it been running in Chrome since February this year when 9 was released?

If you did want to disable it you can do so with the following command line option:

--disable-ssl-false-start command-line

False Start works by reducing the amount of data that must be exchanged when a webserver and browser are negotiating an SSL session. Under official SSL specifications, two round-trip passes of data must be exchanged before an encrypted tunnel is established. The requirement adds latency that can slow down the time it takes pages to load and increase the packets websites must process.

Latency “makes a difference in does it feel snappy or does it feel sluggish,” said Marsh Ray, a researcher and software developer at two-factor authentication service PhoneFactor. False Start “certainly eliminates an objection that some people have for SSL, which is that it increases the load time.”

False Start, as described in a proposal Google engineers submitted last year to the Internet Engineering Task Force, makes it possible to reduce the latency penalty of offering SSL to just a single round-trip pass. The technology does this by using an abbreviated handshake when negotiating the key and other variables used in the encrypted session.

Belshe said engineers tested False Start on a list of all known websites that offer SSL and got a 94.6 percent success rate. Almost all of the unsuccessful connections came from sites that were no longer available, leaving a true failure rate of just 0.4 percent. Those sites have now been compiled into a manageable list used to turn off False Start when they are accessed in Chrome.

With all the media coverage from FireSheep – SSL is indeed a big issue now so this might come as a pleasant surprise for heavy SSL users.

You can read the entire paper here:

Transport Layer Security (TLS) False Start

Let me know your thoughts? Yah SSL is already a big mess, but does this make it worse?

Source: The Register

1. Works if scapy doesn’t drop packets. using pcap instead of SOCK_RAW helps a lot now.
2. Works better on interactive traffic with no traffic at the time of the ptrace. It follows the flow, after that.
3. Dumps one file by fd in outputs/
4. Attaching a process is quickier with –addr 0xb788aa98 as provided by haystack INFO:abouchet:found instance @ 0xb788aa98
5. how to get a pickled session_state file : $ sudo haystack –pid `pgrep ssh` sslsnoop.ctypes_openssh.session_state search > ss.pickled

Not all ciphers are implemented.

Workings ciphers: aes128-ctr, aes192-ctr, aes256-ctr, blowfish-cbc, cast128-cbc
Partially workings ciphers (INBOUND only ?!): aes128-cbc, aes192-cbc, aes256-cbc
Non workings ciphers: 3des-cbc, 3des, ssh1-blowfish, arcfour, arcfour1280

It can also dump DSA and RSA keys from ssh-agent or sshd ( or others ).

You can download sslsnoop here:

trolldbois-sslsnoop.zip

Or read more here.