Encryption’s role in digital transformation

How encryption can be the answer to cybersecurity and business development in the complex world of digital transformation, regulations and cyber threats.

The beauty of encryption is in the simplicity of its approach. Security is applied directly on the data itself, not to the network perimeter, devices or servers. It doesn’t matter if that data is in the cloud or in a 3rd party data center, only the appropriate key holder will be able to access it. It doesn’t matter if hackers bypass network perimeters or if administrators with privileged rights access sensitive systems, encryption keeps the data safe, as long as the key is in the right hands.

Business development generates new valuable data flowing in new systems to new partners and customers in an ever-increasing speed of change. Proper encryption can protect this new data independently of the new environments that the data flows through or is stored in. With the right key management solutions, your data is under your control. Wherever it is, no matter the circumstances.

Hyker Full Lifecycle Encryption means encryption without compromise – end-to-end, over time in an unbroken chain. Data is never exposed in clear text which means that there are no vulnerable system handovers. With automatic key distribution, removing many of the complexities and difficulties of implementing encryption. Simple implementation means huge cost savings in your Digital Transformation projects.

Why you should read this post

This post discusses encryption and its benefits. Usually, cybersecurity is regarded as a cost, but with the right strategy and implementations, encryption can be a cost saver as well as an enabler for digital transformation and new business opportunities.

  1. We start with a somewhat technical overview of what encryption is. This is important since encryption gives radically different results depending on how and where its implemented. Just saying “it’s encrypted” really doesn’t mean anything from a security point of view.
  2. The important thing is; who has access to the encryption keys and how keys are managed and distributed. This is the subject for the second part of this post.
  3. The third and last part discusses how encryption can help you in regulation compliances.

Encryption fundamentals

In short:

  • Encryption is a process that transforms digital information into a completely unreadable state.
  • The process is reversible only to the ones that can provide the correct digital key.
  • When encryption is applied correctly, stolen data is useless.
  • Encryption protects data itself, whereas traditional IT security protect the network perimeter and devices
  • Encryption can provide both confidentiality and integrity.

Encryption is a system that modifies data so that it can only be read by certain people. Encryption scrambles data — such as an email or file — using a mathematical algorithm called a cipher. A string of data, called a cryptographic key, works like a password to protect the file. Once the data is encrypted, it looks like meaningless gibberish to anyone trying to access it. Once sensitive information is encrypted, the protected data can pass through any system without being accessible. The only way to read it is by using the key to decrypt (unscramble) the data.

Encryption gives radically different results depending on how and where its implemented. Just saying “it’s encrypted” really doesn’t mean anything from a security point of view.

Perimeter Protection vs Data Protection

conventional cloud security leaves security holes

Traditionally encryption was used to protect a specific message or document of high value, especially important when the document was no longer in the hands of the creator/owner. At home you protect the document by putting it in a safe and your home was protected by a wall around the village.

When written documents became files and communication became digital there was still the same need to protect the valuable data. The village is replaced by private networks and firewalls. Files and data are stored in servers and clouds and can be encrypted “at rest”. Communication links can be encrypted “at transfer” in a secure tunnel (TLS, VPN, etc.).

But, you will be breached.

Even if your network has the latest firewalls, your communication links are protected with state-of-the-art tunnel encryption, like TLS, and databases are encrypted with AES-256, there will be holes between the systems where data is in clear text and at risk.

Security is today a mashup of technologies, everyone extremely good at protecting their part, but leaving vulnerabilities in-between.

The ever-increasing number of network breaches and data leakages shows that organizations can no longer rely on perimeter security alone to secure sensitive data and intellectual property. And, it is not just perimeter defenses that are struggling, as many older encryption solutions were built before mobility, BYOD, the cloud and Web.

There is a need for alternative approaches to protecting sensitive information. Organizations must turn to modern encryption solutions that fully address the hard truths of protecting data in today’s quickly changing and highly complex digital world.

Enters end-to-end encryption technology.

Hyker security model provides necessary encryption for digital transformation

For encryption-based data security to be effective, the data must be protected at the point of origin. If the data is encrypted as the very first step in the process, it is secure no matter where it goes, over what network it is transported and where and by whom it eventually is stored.

Doing otherwise, like most do today, requires the trust of every computer, every network connection and every person from the point that the information leaves the originator’s care, and for as long as it or any copies exist.

Encryption and CIA

CIA is not referring to the Central Intelligence Agency in this case. CIA refers to Confidentiality, Integrity and Availability, the cornerstones of information security. Confidentiality of information, the integrity of information and availability of information.


When we talk about the confidentiality of information, we are talking about protecting the information from disclosure to unauthorized parties, and this is really the reason why encryption was ever invented.


The integrity of information refers to protecting information from being modified by unauthorized parties, i.e. that you can trust the information to be right.

Cryptography offers methods for protecting and inspecting the integrity of digital data in the form of signature functions. These functions are analog to ordinary physical signatures, i.e. they provide proof that the data has been produced/approved by the signing party. Digital signatures also have the advantage of a strong guarantee that none of the data has changed since it was changed.


Availability of information refers to ensuring that authorized parties are able to access the information when needed.

Information only has value if the right people can access it at the right times. Denying access to information has become a very common attack nowadays. Almost every week you can find news about high profile websites being taken down by DDoS attacks. The primary aim of DDoS attacks is to deny users of the website access to the resources of the website. Such downtime can be very costly. Other factors that could lead to a lack of availability of important information may include accidents such as power outages or natural disasters such as floods.

Cryptography does not provide any support for availability, but as discussed in this post, cryptography is very much about the distribution of encryption keys. It is therefore important to design the cryptosystem with the availability of keys in mind, without reducing confidentiality and integrity protection. For instance, depending on the use case, you must consider where keys are stored, and access is managed.


Other factors besides the three facets of the CIA are also very important in certain scenarios, such as non-repudiation.

The concept of non-repudiation is particularly important for financial or e-commerce applications. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.

For example, a customer may request a transfer of money from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request, that the user authorized the transaction.

Hyker Full Lifecycle Encryption is built upon all these fundamentals, simplifying the implementation of encryption in any application or system. Confidentiality, Integrity, and non-repudiation are already built in. Availability will always be use case dependent, but Hyker provides mechanisms like key delegation for the implementation of a robust system.

Symmetric Key Cipher

One of the most used encryption standards is called Advanced Encryption Standard (AES) and was published in 2001. It is still used today for everything from business records, to top-secret government data. Common uses for AES are file encryption (e.g. creating an encrypted zip-file with WinZip), hard drive encryption (e.g. BitLocker) or VPNs.

The AES is a symmetric key cipher, supporting 128, 192, and 256-bit keys. Every bit doubles the amount of time it takes to break an encryption key. Even with the fastest supercomputer, it would take about 1 billion billion years, just to crack a 128-bit AES key.

A symmetric key cipher means that it uses the same key to encrypt and decrypt the data. Even though the key lengths make AES practically impregnable the fact that you have the same key to encrypt and decrypt makes it more difficult to keep the key secret from unauthorized viewers.

You must find a way to send the key to the recipient if he doesn’t have it yet. Otherwise, your recipient won’t be able to decrypt the files you send him. Whichever way you do it, it must be done in a secure manner or else anyone who gets a hold of that key can simply intercept your encrypted file and decrypt it with the key.

The issue of key distribution becomes even more pronounced in an enterprise environment, which can involve many users and likely distributed over a vast geographical area, sometimes halfway around the world. Distributing a symmetric key in a secure manner to each of these users would be nearly impossible.

Asymmetric Key Cipher, or Public Key Cryptography

Asymmetric key encryption doesn’t have this problem. It uses two keys: one to encrypt data, and one to decrypt it. It’s often referred to as public key encryption because people who use it make the encryption key public but keep the decryption key private. Anyone can send them an email or file encrypted with their public key, but only they can read it, using their private decryption key. As long as you keep your private key secret, no one will be able to decrypt your encrypted file. You can easily distribute the corresponding public key without worrying about who gets a hold of it.

Public key encryption is fundamental for various Internet standards, such as TLS, S/MIME, and PGP. Public key cryptography is used as a method of assuring the confidentiality, authenticity, and non-repudiability of electronic communications and data storage.

Hybrid Cryptosystems

Symmetric key ciphers have the problem with sharing keys. And asymmetric key ciphers are complex and computationally intensive. To get the best of both worlds it is today a common solution that you combine these two methods into a hybrid solution.

These systems use asymmetric keys to initially encrypt symmetric keys known as session keys. The session keys are then the ones used to encrypt the actual data. As its name implies, a session key is only used in one session. After the session, the key is simply discarded. That’s a good thing because even if a session key is compromised, only data sent within that particular session will be at risk.

Examples include the TLS protocol which uses a public-key mechanism for key exchange (such as Diffie-Hellman) and a symmetric-key mechanism for data encapsulation (such as AES). TLS/SSL is most commonly known as the (S) in HTTPS that secures access to websites.

Another example is Hyker Full Lifecycle Encryption, where the data is protected end-to-end from a data producer to a consumer in an unbroken chain, anywhere, over time, in transfer and at rest. Read more about the Hyker RIKS protocol.

Encryption Key Management is the real challenge

In short:

  • Encrypting data is easy.
  • The difficult thing is the distribution of encryption keys to the right users.
  • Key management is also about generating, storing, distributing, rotating, revoking, suspending and terminating keys.
  • Authentication is the process of verifying an identity before giving access to data (“using the key”).

Key management is one of the most challenging aspects of cryptography because it deals with many types of security challenges beyond encryption, such as user authentication and behavior, organizations and flawed policies.

There are also aspects depending on the use case and system requirements;

  • Should you have a centralized key storage?
  • What about latency and the risk of system failure?
  • Where should you put your trust?
  • How much can you trust the users?
  • How should they authenticate themselves?
  • Do they bring their own devices – BYOD?
  • How should they receive the key or keys?
  • One key per system, device or data element?
  • How much can you trust the central nodes or cloud providers?
  • How dynamic should the system be?
  • How often will it change? How often will users come or leave?
  • What regulatory requirements do we need to follow?

All these questions have technical and system design implications. Also, an organization with many systems might end up with many different answers to all these questions and then need a common model to make it all manageable.

The 3 approaches to Key Management

There are many key management protocols from which to choose, and they fall into three categories:

  • Distributed: End users are 100% responsible for their own key management. The organization requiring the use of encryption provides no support for handling key governance.
  • Decentralized: Each department in the organization establishes its own key management protocol. There may or may not be coordination between departments.
  • Centralized: There is one focus for key management across the entire organization. All users follow the same key management protocol.
Hyker Full Lifecycle Encryption has an inbuilt automatic key sharing service where you, depending on the needs of the organization and use case, chose the level of centralization and distribution needed at the design stage.

The choice of model is highly dependent on the use case

When to use a Centralized model

traditional delegated adminstration

The centralized model has its obvious advantages, with a single point of control that vouches for easier management of resources, data, users and access rights. It creates a uniform key management across the organization, supporting people as they move from department to department.

A fundamental requirement for a centralized model to be suitable is that you must have full control and ownership of all the data and resources in the system. This is often the case for internal systems run in own data centers in a private network or a private cloud, but not if you use 3rd party cloud services like Dropbox, Salesforce or similar, that have their own security setups, processes, staff, and sub-suppliers.

This is also not the case if your system has users which are not under your control by employment or similar. There are many vendors in the market that tries to bridge this problem providing you with central control over 3rd party services, but it still often comes down to the simple question; “who has the keys to your data?”.

Another drawback is performance, both when it comes to system latency and organizational. With central systems, you need a large IT organization to manage the day-to-day changes of users and access rights. It quickly becomes a bottleneck with long waiting times to let a new user in the system, to approve or remove access rights to specific data, to set up ad-hoc projects, etc. This prevents agility and slows business development. In fact, this is a major reason for users turning to less secure external tools to get their job done, so-called shadowIT.

When to use a distributed model

automatic dynamic group managment

A distributed model means that you delegate encryption key storage and management of access rights and users out in the organization, to the place that should know their operation and users the best.

Sometimes a distributed model is the only solution when you have high-security requirements. When information is stored and shared in applications that are shared between organizations or in different 3rd party environments you are forced to trust these applications or partners because of their centralized trust model.

Examples of this are communication systems like Gmail, Microsoft Outlook or Slack, filesharing systems like Dropbox, Microsoft OneDrive or Google Drive and SaaS applications like Salesforce or Microsoft Office365.

If you cannot trust these partners, for operational or regulatory reasons, you are in trouble. If they have a distributed encryption model implemented they can provide you with a full service without ever having access to the data in their service. You maintain all the keys to your data. So, be very careful when you select a 3rd party or SaaS solution. Ask them who has access to your data, and how you can prevent that.

As mentioned above, centralized models might also have performance bottlenecks that can be addressed by pushing key storage and management further out in the network, closer to the usage of the keys. For instance, when you encrypt large amounts of smaller data elements, that requires high availability and usage, then huge amounts of keys need to be transported across the network. It then makes sense to have those keys stored more decentralized.

Hyker Full Lifecycle Encryption provides a plug-in SDK for these kinds of services, turning them into true end-to-end encrypted services, where the customers manage their own keys.

Regulatory Compliances – It’s all about Data Control

In short:

  • Regulations are mostly about control and data protection
  • Most data protection requirements can be fulfilled by encryption

The number of global and regional regulations and mandates has increased over the past few years, as has the scope, complexity, and cost of complying. The guidelines, rules, and interpretations of each regulation continue to evolve, as do the organizations and systems that need to be protected—and the risks they’re exposed to. Compliance has become such a huge challenge that organizations can easily allocate up to half of their IT staff to compliance efforts, including interpreting legal language, implementing solutions, monitoring and responding to regulation updates, and managing different audit reporting requirements.

In this environment, the traditional reactive approach of treating different compliance regulations as siloed projects and implementing them in isolation from other regulations creates duplicate efforts and drives up the cost and complexity of becoming and staying compliant. Instead, many organizations turn to data encryption to achieve compliance with multiple regulatory requirements, enforcing policies by denying access to sensitive data unless the person or entity possesses the proper encryption key. However, the traditional, multiple-point approach to encryption creates islands of security with different encryption systems, key management, and reporting, adding to the complexity and cost of compliance.

Data control and protection is the foundation of most regulations, and a well-designed encryption and key management system will be a tremendous shortcut in your compliance work, fulfilling the data protection requirements for many regulations in parallel.

Some examples of the ever-growing number of regulations:

GDPR – The General Data Protection Regulation (EU)

Encryption and key management, which by design attaches security directly to the data itself, gives organizations the level of data control that GDPR asks. Ultimately, with encryption, only key holders can access the data. The manner – both technically and organizationally – by which organizations restrict encryption key access will ultimately determine access to cleartext data.

Examples of when encryption may be used to easier comply with GDPR:

  • in case of a data leak, companies must within 72 hours report the breach and take action.

    With the many network access points, email accounts, and mobile users you will be breached. The hacker methods of phishing, social engineering, and zero-day exploitations evolve faster than the preventive measures from IT security. Today, a hacker can operate in a network without leaving any trace for months, making it extremely difficult to notice a breach within the stipulated 72 hours. Unless the data is inaccessible by protective encryption that renders the data inaccessible. Then the network breach is not the same as a data leak.
  • as a data processor, you are just as responsible for protecting the data as the data owner (controller).

    If the data is encrypted and keys kept by the data owner (controller), you do not need to implement extra measures. You manage the controller’s data without having access to the information within the data since you cannot access it without access to the encryption keys.
  • the right to be forgotten

    This is very hard to implement in most organizations since the data resides in many copies in many places, for instance, backups, emails, local PCs, etc. If the data element is encrypted with a unique key, it is enough to revoke the key for this data element from the key management system. The data will be in-accessible wherever it resides and thus is “forgotten”.

Cloud Act – The Clarifying Lawful Overseas Use of Data Act (US)

The Cloud Act is basically an update to the Electronic Communications Privacy Act (ECPA) from 1986, a series of laws that regulate how U.S. law enforcement officials can access data stored overseas.

Through the Cloud Act, U.S. law enforcement officials at any level, from local police to federal agents, can force tech companies to turn over user data regardless of where the company stores the data.

This has huge implications for anyone storing data by a US cloud provider. Can you trust them to keep your data secret? The simple answer is no, which makes it in many cases illegal to utilize their services. For governments, there are laws preventing agencies to store sensitive information on foreign data centers, but now it will be illegal for many enterprises too. For instance, if you are handling EU citizens data you have a problem if US authorities force your 3rd party supplier to hand over your customers’ data. Then you are in breach of GDPR.

Encryption can be the tool to save the day, as long as the cloud provider never has access to the encryption keys. Without access to the data, they have no possibility to leak it.

HIPAA – The Health Insurance Portability and Accountability Act (US)

The purpose of HIPAA is to protect the privacy of individuals’ health information while allowing organizations to adopt new technologies to improve the quality and efficiency of patient care. HIPAA is designed to be flexible and scalable so a covered organization can implement policies, procedures, and technologies that are appropriate for the organization’s size, organizational structure, and risks to consumers’ data.

Encryption isn’t technically mandatory under HIPAA, but it stipulates that encryption should be implemented if an organization finds it would safeguard the patient’s data. Otherwise, it needs to implement an alternative to HIPAA encryption and document why it did so. Documenting is important, especially in the case of an audit. So, encryption (or its equivalent) is required if it’s reasonable and appropriate to encrypt, which it usually is.