Express/­­­­­­­DomainSSL certificates

We are changing from using an issuing CA that chains to the GlobalSign Root R1 which is an SHA-1 Root, to the GlobalSign Root R3 which is an SHA-256 Root.

The GlobalSign Root R3 has been in use for several years issuing our EV/Extended Validation SSL certificates, and now we are moving our Express/DomainSSL issuance to this Root.

This new CA under Root R3 will be used to sign both RSA and ECC certificates.

Business/OrganisationSSL certificates

We are changing from using an issuing CA that chains to GlobalSign Root R1, to CAs that chain either to GlobalSign Root R3 or GlobalSign Root R5.

All requests for RSA Certificates will be issued under a new RSA Intermediate CA which chains to GlobalSign Root R3, while all requests for ECC Certificates will be issued under a new ECC Intermediate CA which chains to GlobalSign Root R5.

The entire chain from SSL Certificate to the Root will be consistent with respect to the key type and signing algorithms (SHA256RSA and SHA384ECDSA).

EV/Extended Validation SSL: Certificates issued from a Managed SSL account

Our EV SSL certificates, issued from a Managed SSL account (where pre-vetting is a feature), will continue to use the existing Intermediate CA for RSA keys but will use a new ECC intermediate CA that chains to GlobalSign Root R5 for ECC keys which permits a complete ECC chain.

EV/Extended Validation SSL: Certificates issued from a non-Managed SSL account:

No change – the intermediate CA for EV SSL certificates from a non-Managed SSL account will continue to use the current intermediate CA that chains to R3 (this concerns both RSA and ECC certificates).

Any Question? Request a Call

Name *

First

Last

Company *

Business Email *

Phone *

Comment or Message

SUBMIT

Updated 5/9 2019: The Danish Financial Supervisory Authority (Finanstilsynet) has decided to postpone the hard deadline for Danish compliance with PSD2 until March 14, 2021. This extension of the implementation period only applies to online card payments.

PSD2 explained

In short, the Revised Payment Services Directive (PSD2) is a stricter requirement for European financial institutions.

The purpose of PSD2 is to increase transparency and the free choice for suppliers of financial products between European countries and to secure the consumer through Strong Customer Authentication (SCA).

This video gives a pretty good overview of the PSD2 directive and its contents.

Qualified Certificates are now required

One of the essential parts of PSD2 is the requirement for Qualified Certificates:

As one of very few European organizations, TRUSTZONE provides Qualified Certificates to both Third Party Providers (TPP) and Payment Service Providers (PSP).

QWAC and QSEAL

There are two different types of certificates:

• Qualified Website Authentication Certificate (QWAC)
• Qualified Certificate for Seals (QSEAL)

In our experience, most financial institutions need both types of certificates to become 100% PSD2 compliant.

What to do next

Our recommendation is that you review your upcoming certificate needs as soon as possible.

We hope that the extension of the current implementation period result in complacency:

On the contrary, we strongly encourage companies, organizations, and financial institutions who aren’t yet compliant to contact us. We’ll be happy to help you clarify which certificates you need.

Get in touch with us for a non-binding quote

Full name *

First

Last

Company *

Business Email *

GDPR Agreement *

• By signing up, I agree to TRUSTZONE’s Privacy Policy *

REQUEST PRICING

The new requirement

As of January 1, 2019, all operators in the German energy sector (the energy and water industry market) are required to use the RSASSA-PSS algorithm to ensure secure email communications with market participants.

Who does this affect?

Among others, this new RSASSA-PSS algorithm requirement will affect companies with business relations in the German energy sectorbut who have not yet have not switched to the RSASSA-PSS algorithm to ensure secure email communications.

Rejection of invalid digital signatures

As of January 1, 2019, all operators in the German energy sector (the energy and water industry market) are required to use the RSASSA-PSS. However, signatures with both SHA-512 and SHA-256 have been allowed until the end of July 2019.

As of August 1, 2019, signatures with both SHA-512 and SHA-256 are no longer accepted. In practice, this means that digital signatures not using the RSASSA-PSS algorithm are considered invalid and will be rejected from August 1, 2019, and onwards.

TRUSTZONE’s email certificates

We provide S/MIME secure email certificates that fully comply with the RSASSA-PSSS algorithm requirements.

Request Pricing

Full name *

First

Last

Company *

Business Email *

GDPR Agreement *

• By signing up, I agree to TRUSTZONE’s Privacy Policy *

REQUEST PRICING

Is encryption required?

You could easily be led to believe that the Danish Data Protection Agency makes a new non-negotiable requirement for encryption of emails if you read the press release, “Stricter practice in relation to encrypted emails”, issued by the authority on 23 July 2018.

That is, however, not the case.

The approach by GDPR and the Danish Data Protection Agency to safeguard personal data is risk-based.

It means that the higher the risk that personal data falls into the wrong hands and the larger the adverse effect it may cause, the better you will have to safeguard your data.

Encryption is a possible security measure, but it all depends on your infrastructure and the individual categories of data you must secure, as one of the technicians of the Danish Data Protection Agency told us.

Risk assessments are mandatory

However, the Danish Data Protection Agency has a deadline for compliance with GDPR in the field of emails:

As per January 1, 2019, businesses must have secured personal data, which is distributed both internally and externally through emails.

But how do you become compliant when security depends on infrastructure? How can your specific business avoid potential fines from the Danish Data Protection Agency?

In this respect, the Danish Data Protection Agency could have worded their requirements a bit clearer.

However, the agency’s information material and statements to the press outline a procedure:

The first thing you have to do is to make a risk assessment. This is mandatory—everybody who distributes personal data through email must make one.

How to make a risk assessment

A risk assessment consists of:

1. A mapping of all the risks that the processing (of personal data, editors) entails and a categorization (scoring, likelihood, and severity) thereof
2. An assessment of what constitutes adequate technical and organizational measures to ensure that the regulation is complied with

Some businesses also have to make an impact assessment. Both assessments will shed light on how the infrastructure of the business is designed, which personal data that the business sends, and how these data should be protected.

Encryption applies to confidential and sensitive personal data 

Personal data is not just personal data. They come in three different categories that should be safeguarded at different levels.

When the Danish Data Protection Agency speaks about encryption, this typically applies to the so-called confidential and sensitive personal data.

Encryption during transmission could mean forced TLS

Encryption is also a broad term. The Danish Data Protection Agency talks about encryption during transmission (or submission), which is different from encryption at rest or what is also called end-to-end encryption.

TRUSTZONE delivers end-to-end encryption through our PersonalSign certificates.

If we are going to express it in technical terms, the most widespread type of encryption during transmission is what is called Forced TLS (Transport Layered Security).

These days, most mail servers support TLS. That applies to e.g. Gmail, Outlook and Hotmail.

If both parties support the technology, TLS will encrypt your email on its way from the sender to the recipient. That is, during the transmission.

That takes place in the same way as a connection is encrypted between a browser and an https-secured website server.

TLS creates a kind of tunnel between the sender and the recipient. A third party cannot, e.g. through malware – capture, read and involve in the communication.

The contents, i.e. emails sent forth and back through the tunnel, are not encrypted, but the communications channel through which the contents passes, is. That way, third parties are prevented from looking through the walls of the tunnel and gaining access to the contents.

However, it is a problem that the standard TLS setting on chiefly all mail servers is only “opportunistic TLS”.

This means that the sender’s server prefers TLS during transmission (but makes no requirement to that effect).

If the recipient’s mail server does not support TLS, the email will nonetheless be sent to the recipient’s server, which in this case is typically an unencrypted POP3 or SMTP server.

Thus, the communication can be captured, manipulated or otherwise compromised relatively easy.

The same applies on the way in the transmission. In some scenarios, a hacker can arrange that TLS server stations are missing en route, and if there are no alternatives, the sender’s mail server will use an unencrypted server as an intermediary station. Here, the communication can again be captured and compromised.

However, the problem can be avoided by using the setting “Forced TLS”. With this setting, the mail server requires that the recipient’s server and stations in transit all use TLS.

If there are servers en route that do not support TLS, the sender gets a message that the email cannot be sent to the said address.

This setting, this type of encryption will “normally (… ) be a suitable security measure – to both public and private players (… ) in the transmission of confidential and sensitivepersonal data by email through the internet.”

This is the way we must interpret the message from the Danish Data Protection Agency.

According to an article in Version2, the Danish Data Protection Agency further recommends that as a minimum it is the second-most recent TLS 1.2 with the AES standard that the businesses should use for encryption during transmission.

Forced TLS poses problems

There are reasons why Forced TLS is not simply set as a new default setting on marked leading mail servers supporting TLS (Gmail, Outlook, Apple mail etc.).

According to German IT security expert Hanno Böck, there are several major issues at play:

“One obvious problem is that the setting prohibits mail servers from talking to other servers not supporting TLS.

Actually, a German mail host began offering such an option but explicitly warns that it might stop emails from being delivered. Notably, the second-largest political party in Germany opposed STARTTLS.”

But, Böck continues, there’s a more elusive problem: “The certificate issue. [note: Böck refers to the fact that many mail servers don’t have valid certificates and that generally speaking, mail servers, don’t consistently check certificate validity –Ed.].

“Even if certificates were successfully validated, there would still be other issues”, Böck concludes. He suggests this blog article as background reading.

Forced TLS is not always secure enough

But how certain are you then that you’re complying with GDPR in this area?

Well, if it turns out that a hacker would somehow gain access to your email account, then encryption during transmission would not prevent the hacker from reading, changing, or cheating persons by sending emails in your name.

In such cases, Forced TLS will neither curb breaches of the confidentiality, integrity, or authenticity of data.

The hacker could gain access by guessing or finding out your password or the recipient’s password. In semi-open and easily accessible office environments, hackers would fairly easily be able to steal personal data while the responsible employees were absent.

Have a look at e.g. the small offices along the corridors of Denmark’s hospitals. Here, security should perhaps be increased to protect the patient files which contain very sensitive data.

It is with such contemplations at the back of the mind that IT experts and specialists apparently think that the Danish Data Protection Agency sets the bar low by its focus on encryption during transmission. Forced TLS creates a good basis, the point is, but it rarely becomes an adequate solution in itself.

Encrypted external email communication

You can use the S/MIME technology of the PersonalSign certificates to encrypt the contents of your emails and not only the communications channel (the tunnel) between the sender and the recipient.

But we cannot use PersonalSign to encrypt the contents of emails that are sent to private individuals:

Encryption and decryption (of contents, mind you) require that both the sender and recipient have an S/MIME certificate installed on their devices. We cannot expect that from the general private individual or our B2B contacts for that matter.

In the external communication, a PersonalSign certificate can nevertheless contribute by a digital email signature. The recipient can easily see that without a certificate on its device.

With a digital signature, you confirm your identity as a sender of the email, and you confirm that the contents of the email have not been changed during the transmission.

If the contents had been changed, the recipient will not be able to see the signature.

With S/MIME, you confirm the authenticity and the integrity of data to external parties. The certificate contributes to an extra security layer in relation to Forced TLS. In addition to man-in-the-middle attacks (MITM), it protects against phishing and spear phishing in external communication.

Summary

As for external communication, a PersonalSign certificate will provide the following additional value in addition to Forced TLS:

• A digital signature, i.e. safeguarding of the integrity of data and the authentication of the sender 
• Protection against phishing, spear phishing, MITM attacks, malware, and more

Internal emails: Protecting confidential and sensitive personal data

Often, there is a tendency to email personal data internally than externally out of the organization. Here, PersonalSign can contribute to the possibility of true end-to-end encryption:

When you encrypt an email via PersonalSign, others can not read it unless they have access to the recipient’s email account and, in addition, to the recipient’s private encryption key.

PersonalSign thus delivers the most secure type of email encryption that exists.

A digital signature will also prevent internal phishing and spear-phishing such as CEO fraud.

In short, PersonalSign can add the following increased value in relation to securing data in the in-house communication:

• A digital signature, i.e. safeguarding of the integrity of data and the authentication of the sender
• End-to-end encryption—the confidentiality of data including protection against malware, MITM attacks, phishing, and spear phishing

Get in touch with us for a non-binding quote

Full name *

First

Last

Company *

Business Email *

GDPR Agreement *

• By signing up, I agree to TRUSTZONE’s Privacy Policy *

REQUEST PRICING

The rebirth of an old attack

The predecessor of the ROBOT attack attack was found in 1998 by the cryptographer Daniel Bleichenbacher. It also became known as the “Million Message Attack.”

The exact details are complicated, but the basic idea of Bleichenbacher was this: By sending specially crafted faulty SSL messages to a server, he was able to learn tiny pieces of information about a ciphertext depending on what type of error the server was sending.

By sending enough messages, he could learn more and more and finally be able to fully decrypt something with the server’s private key.

A more secure cryptographic protocol

Over the years other researchers have found variations of Bleichenbacher’s attack and also improved it, so it doesn’t require “Million Messages” anymore
—a few thousand are usually enough.

In 1998, SSL was officially renamed to TLS, and the first version (1.0) was the first properly standardized encryption scheme for the Internet.

TLS 1.0 contained countermeasures to Bleichenbacher’s attack. However, it turned out that the countermeasures were insufficient. Later TLS versions—the current one is version 1.2—carried more complex countermeasures.

Vulnerability in 27 percent of Top 100 websites

What we found is that these countermeasures often aren’t implemented correctly. Attacks that are very similar to Bleichenbacher’s initial attack still work against a large number of TLS devices and hosts.

Particularly expensive appliances that are often used by large web pages were vulnerable:

Looking at the top 100 web pages (according to the Alexa Top 1 Million list), 27 of them were vulnerable when we started this research. When scanning the whole Alexa Top 1 Million list, the fraction of vulnerable web pages was around 27 percent of the top 100.

Moving away from RSA encryption

TLS supports different encryption modes. The risk depends on the cipher modes used. Traditionally TLS and its predecessor SSL used RSA to encrypt a secret that was later used to secure a connection.

This traditional RSA encryption mode is most vulnerable to this attack. An attacker can simply observe and record traffic and subsequently use the vulnerable server to decrypt that data.

Forward secrecy as a better cipher mode

But the TLS ecosystem has mostly moved to better cipher modes. These still use RSA, but not for encryption. Instead, RSA is used as a signature algorithm, and the encryption key is negotiated with a key exchange algorithm.

These modes have a significant advantage: They provide a property called “forward secrecy.” That means that even if the key of a server gets stolen by an attacker, this doesn’t allow the attacker to decrypt traffic from the past. The forward secrecy cipher modes use Diffie Hellman or Elliptic Curve Diffie Hellman.

The use of forward secrecy in practice

It turns out that these forward secrecy modes also have advantages when it comes to Bleichenbacher attacks. While it is still possible to attack these modes, it’s far more challenging.

An attacker would have to perform the whole attack during a handshake, which usually takes between milliseconds and a few seconds. As the attack takes several thousand requests to a server, this is difficult to perform in practice. Furthermore, this is only possible if a server still supports the vulnerable RSA encryption mode.

RSA encryption should be updated or replaced by ECC

One conclusion we draw from our research is that the RSA encryption modes should be disabled:

Based on some observations on our servers and also based on data we got from Cloudflare, we believe that the number of legitimate Internet connections that still need these old encryption modes is very low.

Still, disabling RSA encryption can result in compatibility problems and may lock out users with old clients.

Particularly on email servers, we observed that many users with old Android versions use the old ciphers to log in. It is still better to offer TLS with RSA to those old clients than not using any encryption at all.

For those who don’t want to go that far and disable the RSA encryption modes, several vendors are providing updates. For affected devices from F5 and Radware, firmware updates are available.

Furthermore, the open-source TLS implementations from Erlang and WolfSSL have implemented fixes.

We identified more vulnerable vendors: The ROBOT web page contains a list of vulnerable vendors that will be updated once more information becomes available.

Old attacks keep coming back 

There are a few things to learn from the ROBOT attack: Like many other “famous” attacks on cryptography and TLS in the past years, it’s a new variant of an old attack.

DROWN was also a variant of Bleichenbacher’s attack, and many other attacks like BEAST, Lucky Thirteen, or Logjam were based on known weaknesses in cryptographic algorithms and constructions.

Compatibility an obstacle for a safer cipher mode

In the case of Bleichenbacher’s attack, the designers of TLS decided to propose incredibly complex countermeasures. With each new TLS version, the chapter describing these countermeasures became longer.

There would have been alternatives. There are safer RSA encryption modes, and the TLS designers could also have decided to move to forward secrecy earlier. But to retain compatibility, they decided to keep the old, dangerous RSA encryption mode.

RSA encryption will die when TLS 1.3 is introduced

With TLS 1.3, this will change. It no longer contains RSA encryption modes. However, that doesn’t necessarily mean that the risk is eliminated.

As previous research by a group of German cryptographers has shown: If the old RSA encryption modes are supported for old versions of TLS, they still pose a risk to modern protocols like TLS 1.3 or Google’s QUIC protocol.

The only safe way to get rid of ROBOT and Bleichenbacher’s attack is to fully disable RSA encryption in TLS.

A warning sign meeting the end user 

Google Chrome’s security team has announced that around October 24, 2017, a new warning sign will meet end-users browsing in Chrome.

Specifically, it’s when users enter data in input fields on HTTP pages that the warning message will show up.

It is not only obviously sensitive information such as credit card information or passwords that will trigger the warning message, but rather any kind of input field.

This goes one step further in Google’s strategy on protecting end-users browsing the internet: With the launch of Chrome 56 in January 2017, all HTTP websites containing input forms for passwords and credit card information were marked with a “Not secure” warning message.

Google now takes the next step towards protecting end-users against spoofing and other types of cyber attacks.

The launch of Chrome 62

From around October 24, 2017, Google will launch Chrome 62.

In this browser version, the “Not secure” warning will appear on all HTTP pages when the user starts entering data in any input form.

Moreover, in Chrome Incognito mode, the warning message will show at page load and be constantly visible when visiting an HTTP site.

Potential consequences for websites

If you haven’t installed an SSL certificate on your website yet, you should consider installing one:

Not reacting could mean negative consequences for your website, and possibly for your online business.

If your potential customers are met with a warning message when entering personal information in your website’s input form, there is a potential risk that they’ll interrupt the session and the purchase, and chooses to make the purchase at a competing website.

End-users have learned to look for the padlock symbol, and to know that this is an indicator of safe browsing.

Therefore, if the browser shows a ‘”Not secure” warning instead of the green padlock symbol, it might have an impact on the conversion rate for your website.

The announcement from Chrome’s security team also alerts to future changes: Eventually, the warning message will be shown on all HTTP pages.

Since Google is a trendsetter in browser security, we might expect other browsers following Google’s standards.

HTTPS in relation to SEO

In 2015, Google announced that HTTPS websites would have a larger likelihood of ranking high in the search engine results page (SERP), compared to HTTP websites, if the two pages were equal on other parameters.

That means HTTPS is not only important for website security and user trust but also important for SEO.

It seems like it is worth the effort to apply HTTPS on web pages: According to mozcast.com, HTTPS pages are now shown more frequently than ever in Google search results.

The steady rise in HTTPS search results can be caused both by Google favorizing HTTPS pages in Google’s algorithm, but also by a general rise in the number of HTTPS pages in the web:

In organic searches, it is important to be found on SERP [short for “Search Engine Results Pages” –Ed.] #1, since click-through rates (CTR) generally drop dramatically when turning to SERP #2.

Internet Ninja Marketing conducted a survey with 20,000 search queries over a period of 3 months, showing that CTR [short for “click-through rate” –Ed.] is around 20% on result #1, CTR around 10% on result #2. Below this, CTR flattens out to around 1.5% from #8 – #20.

When using SEO to create a competitive advantage for your company, an SSL certificate will ensure HTTPS on your website, thereby increasing the likelihood of ranking higher in Google search results, and in the end a higher CTR. It’s about conversions, for you and your business!

3 reasons for buying an SSL certificate 

It is important to have an SSL certificate installed to your website. Here are three good reasons to get one.

• Website security: You need HTTPS to ensure encryption of sent content
• SEO ranking: If you want your website to be found in organic searches, an SSL certificate can help you
• User trust: Customers exhibit increasingly conscious behavior online, and a warning message shown in HTTP websites with input fields can have an adverse effect on user trust

The new minimum requirements are detailed about CA policies, covering topics such as certificate contents, revocation and status checking, verification practices, and much more.

While CAs have been hard at work to comply with all of these new requirements, you may be wondering what the changes mean for you.

Let’s take a look at how some of the new requirements will affect those who use these certificates to sign code:

Private keys need to be stored on cryptographic hardware 

According to the CASC, one of the leading causes of Code Signing attacks is key compromise. That is, a malicious party gains access to the private key of a legitimate, “good” publisher and uses it to sign a malicious file, making it look trustworthy and increasing the chances it will be downloaded.

Storing the keys on secure cryptographic hardware, such as a USB token or Hardware Security Module (HSM), significantly decreases the chance of key compromise compared to storing the keys locally (the most common method prior to the new requirements).

We’ve been recommending stronger private key protection for a while now, and it’s been a requirement for Extended Validation (EV) Code Signing Certificates since they were introduced in 2014.

Under the new guidelines, though, it will be required for ALL Code Signing Certificates. Specifically, all private keys will need to be stored on FIPS 140-2 Level 2 HSM or equivalent on-premise hardware, or in a secure cloud-based signing service.

All new GlobalSign Code Signing orders after January 30, 2017, will include a USB token to store the certificate and protect the private key.

Standardized and strict identity verification 

The other leading cause of Code Signing attacks, according to the CASC, is issuing certificates to malicious publishers, who then use the certificate to sign viruses or malware.

To prevent this, the new requirements outline specific precautions CAs must take before issuing, including:

• Strict identity verification about the publisher, including legal identity, address, date of formation and more
• Cross-checking against lists of suspected or known malware publishers, producers, and distributors
• Maintaining and cross-referencing an internal list of certificates that were revoked because they were used to sign suspect code and certificate requests that were previously rejected by the CA

Many CAs already abide by most of these processes, but standardizing makes it harder for a bad publisher to shop around for a CA with weaker vetting procedures if they get rejected by someone else.

Reporting and responding to certificate misuse or suspect code 

In addition to trying to prevent the certificates from being issued in the first place, the new requirements also dictate that CAs operate a “Certificate Problem Reporting” system, by which third parties such as anti-malware organizations, RPs  (relying parties), and software suppliers) can report suspected “Private Key Compromise, Certificate misuse, Certificates used to sign Suspect Code, Takeover Attacks, or other types of possible fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”

CAs are then held to very strict standards regarding how to respond to these reported problems. For example, they must begin investigating within 24 hours and maintain 24×7 communication about any incidents.

There are also strict guidelines and timelines regarding revocation, in the event that malware or any other abuse is suspected.

The new reporting systems mean even if a malicious publisher happens to pass through the verification process, their certificate can promptly be reported, investigated, and revoked.

Another scenario that benefits from timestamping is the event of a key compromise and subsequent certificate revocation:

For example, if your key was used to sign legitimate code, but then later was compromised and used to sign malicious code, you could set the revocation date to be between the two events.

This way, your legitimate code would continue to be trusted, but the malicious code would not.

A safer future for code signing 

The new standards and requirements are an essential step toward cutting down on Code Signing attacks.

Microsoft is the first application software vendor to adopt the guidelines and will start enforcing them on February 1, 2017. TRUSTZONE’s Code Signing Certificates will comply with the new requirements before then.

Get in touch with us for a non-binding quote

Full name *

First

Last

Company *

Business Email *

GDPR Agreement *

• By signing up, I agree to TRUSTZONE’s Privacy Policy *

REQUEST PRICING