Many organizations have adopted DevOps practices to streamline and optimize their development and release processes. By leveraging automation and agile development methodologies, they eliminate unnecessary manual work and speed time to release.
The issue with traditional DevOps is that it still takes an outdated approach to security. Leaving security testing until just before release is a major driver of the thousands of new vulnerabilities discovered each year.
To address this issue, many organizations are making a move towards adopting DevSecOps, which weaves security into every stage of the continuous DevOps lifecycle. However, most developers lack a security background, which can make implementing DevSecOps more challenging. This is where Ubiq can help.
Ubiq is an encryption platform designed to make it easy for developers to secure their data. Effective encryption is essential for protecting against data breaches and achieving compliance with data protection regulations. With Ubiq, developers can easily meet requirements and more intuitively integrate security and encryption into their development process.
The diagram above shows the stages of the Continuous DevOps Cycle. For each stage, the callouts outline the required steps to effectively integrate security into DevOps. The areas where Ubiq can help with improving security and strength of data protection are indicated with bold text across the various stages of the DevOps process.
The Plan stage of the DevOps process covers everything before development begins. This includes gathering requirements and designing a system that is capable of meeting them.
In the modern development world, data security and regulatory compliance are major concerns driving security requirements. If software touches sensitive data or data protected under data privacy laws like the General Data Protection Regulation (GDPR) or the Payment Card Industry Data Security Standard (PCI DSS), then this data needs to be appropriately protected.
The Plan stage of the DevOps process includes identifying the encryption requirements of these regulations and developing a plan to meet these requirements. With Ubiq’s platform, developers have easy access to encryption functions that meet the requirements of all data protection laws.
Once the plan has been hammered out, the development team can start writing code and eventually building release candidates of their application. At this point, the developers need access to encryption functions that meet the regulatory and security requirements identified in the planning stage.
Ubiq’s API includes support for all major programming languages. By importing the appropriate Ubiq library, developers gain access to easy-to-use encryption functions that can be painlessly integrated into their code.
The code sample above shows a sample encryption function in Python. Once credentials have been loaded from a file or explicitly set, encrypting data only requires the developer to make a call to ubiq.encrypt. Behind the scenes, Ubiq configures the encryption algorithm with any necessary parameters and performs the encryption. When access to the data is needed, a call to ubiq.decrypt produces the original plaintext.
After the code has been completed, released, and deployed, it enters the Operate stage of the DevOps cycle. This stage includes everything that could happen while the application is in production use.
From a security perspective, this covers several potential events. Ubiq can help with a couple of them:
The Monitor stage of the DevSecOps lifecycle focuses on identifying and responding to events that no company wants to experience (but most of them will). With Ubiq, management of major security events is simplified and streamlined.
Two examples of how Ubiq helps with DevSecOps monitoring include:
Moving from DevOps to DevSecOps can provide a number of advantages to an organization. It can also be a major lift for developers who need solutions that simplify and automate the process of integrating security into development pipelines.
Ubiq’s encryption platform provides a simple and intuitive option for adding encryption to applications, which is a vital part of data security and regulatory compliance. Try out the Ubiq Platform for yourself to see just how easy it is to implement cryptography correctly and secure any form of application data.
Data encryption is a vital part of data security and many organizations have adopted it. However, data breaches are still a common occurrence. Why is this still happening? Are the methods we’ve relied on still dependable against today’s modern adversaries?
The two most commonly used types of data encryption are at-rest encryption and in-transit encryption. At-rest encryption (such as full disk encryption) encrypts data while it is being stored and is not in use, making it possible to protect stored data against physical threats, but provide full access to data to applications or users as needed. In-transit encryption (like that used in HTTPS) creates an encrypted channel between a network or two computers for them to communicate over; however, it only protects data in transit, not data on the computers or networks themselves.
While these encryption methods are effective at protecting against physical threats (e.g., someone stealing your laptop) and eavesdropping, they do not protect against compromised accounts or privilege misuse. In many cases, malicious attackers simply gain system access and turn them off. What encryption method should we adopt instead?
Like at-rest encryption, application-layer encryption is designed to protect data at rest. However, unlike at-rest encryption, it encrypts data based upon the application that owns it rather than for the storage medium or disk where the data is stored.
With application-layer encryption, data encryption and decryption is performed at the end application. When data is stored or transferred over the network, it remains encrypted until it reaches the destination application that holds the encryption keys. Since keys are only issued to applications on a need-to-know basis, someone with legitimate access to a particular user account does not have full access to all the data stored in that account, only the data relevant to that particular application.
At-rest encryption and in-transit encryption are effective at the very basic task of encryption, but they leave gaps in an organization’s data protection. More specifically, at-rest encryption is in many situations ineffective against modern, network-based attacks. Application-layer encryption enables more comprehensive and robust data protection and can defend a wide range of threats to data security. These include the following:
With at-rest encryption, any account with permissions to access the storage medium will have the data automatically decrypted for them. This creates numerous opportunities for misuse of the permissions associated with an account. Additionally, if an account is compromised by an attacker, that attacker gains access to all data accessible to the account.
With application-layer encryption, having access to the underlying operating system or storage does not provide a malicious actor the ability to decrypt and access the data. Data can only be accessed through the appropriate application, making it possible to enforce appropriate access controls and monitor data use.
High-level encryption solutions, like disk-level encryption, treat all data the same. Sensitive customer information is protected at the same level as a shopping list on a computer. This can mean that most data is over-protected and some may be under-protected.
With application-layer encryption, the application that owns the data is the one that encrypts it. This allows it to tune the protections to the sensitivity of the data or even to specific users and groups. This reduces wasted resources while ensuring that sensitive data is properly protected.
Data protection regulations are becoming more numerous and stringent. A common requirement of these laws is that an organization be able to prove that they restrict access to the data protected under the regulation.
With at-rest level encryption solutions, it can be difficult to determine and prove if a compromised account was used to gain access to data that it has access to.
With application-layer encryption, the granularity of encryption is at the application level. This makes it easy to maintain and demonstrate regulatory compliance because it reduces the ways in which an attacker could gain access to the protected information.
With most at-rest encryption solutions, encryption key management is performed by the encryption software. Often, this means that the encryption key is stored encrypted on the drive while protected by a key derived from the user’s password. While in use, the decryption key is stored in memory, where it may be inappropriately accessed.
With application-layer encryption, the application has control over its own key management. This enables it to use solutions that appropriately protect decryption keys and are compliant with applicable regulations.
Historically, many organizations have used a very permissive and perimeter-based security model. Anyone with legitimate access to a network or system is considered “trusted”, and the security is designed and deployed to protect against external threats.
This security model has its limitations, and the zero-trust security model was designed to address these. Under this model, access to resources is granted on a case-by-case basis determined by access controls. This provides a much higher level of protection, control, and granularity of access controls, which helps to reduce the vulnerability and impact of data breaches. For example, the Capital One breach could not have occurred under a zero-trust security strategy.
Application-layer encryption is necessary for implementing zero-trust security. Alternative encryption methods control access at the storage or disk level, rather than to an individual applications’ data, which makes it difficult to enforce the access controls required in a zero-trust security model.
Application-layer encryption has a number of benefits for the security and performance of an application, and it is not difficult to implement. Ubiq offers libraries for many different programming languages that help developers to integrate encryption into their code and securely and easily provision and manage their encryption keys.
We are often asked about how the Ubiq Platform compares to Key Management System (KMS) or Hardware Security Module (HSM) solutions. In short, an HSM solves a very specific problem, secure key storage, and you can build a KMS using an HSM as a base to provide centralized key storage with policy enforcement. KMS and HSM solutions typically designed for encryption and/or managed by security experts and power users.
Alternatively, the Ubiq platform is a developer-friendly, API-first platform designed to reduce the complexity of encryption and key management to a few lines of code in whatever language you're already using. It requires no security, cryptography, or encryption expertise whatsoever. The platform is built on a KMS and HSM and provides the benefits of KMS and HSM, plus centralized policy management, metrics, and easy-to-use APIs without the boilerplate associated with an HSM or KMS.
Now let’s dive a little deeper into each one so you can see how each works.
A hardware security module is device designed to solve a very specific problem: how can you protect your cryptographic keys from being stolen, even if an attacker gets highly privileged (or even physical) access to your server? The answer is to build an entirely separate computer attached to your main one that can only be used to store and operate on cryptographic keys. That device is designed to be as hardened against attack as possible – it runs a minimal embedded operating system and (hopefully) is heavily tested for correctness bugs that might allow a compromised PC to attack the HSM. It presents a simple interface to the computer that allows for key generation, and import, and allows the PC to request that it sign, encrypt, or decrypt some data. More importantly than the features it offers is a feature it doesn't offer: cleartext key export.
The HSM will allow you to export keys for archival or storage (in fact you probably will have to, since they typically don't have much in the way of nonvolatile storage), but the exported package will itself be encrypted with a key only known to the HSM. The encrypted key blob can be loaded back into the HSM, but is useless without it, so an attacker that gets access to it doesn't get anything useful. Thus, even an attacker that obtains complete control of your PC or server cannot export your keys --- they can still use the keys if they maintain persistent access, but they can't export them, greatly increasing their chance of detection.
So where do you typically find HSMs? They're typically at the root of cryptographic trust chains, holding certificate authority private keys or acting as the main cryptographic key stores for Key Management Systems, which we'll discuss next.
HSM’s seem pretty cool, but they aren't a universal solution to the complex problem of encryption and key management. First of all, you probably have more than one server, and HSMs are expensive, and somewhat complicated to manage at scale. Second, they don't cover all your bases when it comes to enterprise data security or application layer encryption; you still need to handle key rotation, access controls, and other policy-related problems like what encryption parameters to use. The solution to those problems is to wrap your HSM in a Key Management System (KMS), which can be thought of as providing an HSM-as-a-Service.
A KMS will allow you to centrally store your key material, and then set access controls (principal x can encrypt data with this key but not decrypt; principal y can decrypt using these keys but not those ones) - this is important as a defense-in-depth measure, since it means that you can prevent an attacker that compromises a single server from asking the KMS to decrypt all of your data. You can also set policies like which ciphers can be used and combine these primitives into a complex set of policies like handling key rotation and archival or collect metrics about which keys are being used for what operations. However, a KMS is not the whole story for enterprise data encryption or application-layer encryption.
This brings us to the Ubiq Platform. You might be thinking to yourself "Gee, this KMS thing sounds pretty good, maybe I need one of those," and you might even be right. But handling enterprise data security properly isn't as simple as just using an off-the-shelf KMS to interface your servers with your HSM. Using a basic KMS product to implement, enforce, and monitor enterprise-scale encryption is difficult and fraught with subtle mistakes. Actually encoding your enterprise access and key lifecycle policies into KMS access controls is hard and typically involves a lot of boilerplate code to handle key archival and rotation. The same can be said for actually using the KMS to encrypt large amounts of data: a KMS can typically only encrypt small payloads, so you have to handle the “last mile” of encrypting bigger payloads yourself… which is what most application developers need the most help with in the first place!
This is where the Ubiq Platform can help. Ubiq’s end-to-end application-layer data encryption solution abstracts the complexities of policy, encryption, and access controls behind a dead-simple API that also makes it as easy as possible for developers to actually get stuff done. You get automatic key rotation, enterprise-wide encryption policy enforcement, and simple access controls all under a single service that also provides easily understood metrics and a transparent billing process. All it takes is a few clicks and you'll be encrypting data in minutes, backed by the same strong key protection described above, without having to deal with the headaches of actually implementing a full enterprise data encryption solution.
Ubiq never sees your actual data, so it remains private and secure both against attackers and against the platform itself. And Ubiq's client libraries, including the data storage format, are open source, so you don't have to worry about being locked into a proprietary system. Your data remains yours, period.
Quick case in point: A SaaS-based logistics platform company was in the process of implementing encryption to secure structured and unstructured data stored in both Microsoft Azure and AWS clouds across a multitude of different storage types – S3, Blob Storage, SQL databases, Apache Hadoop, to name a few. Before encountering Ubiq, the company spent well over 500 hours of R&D and at least $500,000 on 5 disparate encryption tools and solutions to solve their data security and protection problem. With Ubiq, the customer was able to integrate native encryption controls directly into the application in a matter of 3.5 weeks, providing them a single, consistent solution for encryption and key management across their multi-cloud infrastructure and diverse storage and data types.
|HSM||Secure key storage + operations||Unsuitable. Keys are by design stored only in a single location, which makes application layer encryption impossible without huge effort.|
|KMS||Centralized key management||Suitable with effort. App-layer encryption requires building a large amount of boilerplate client-side code, managing encryption policy manually, and dealing with vendor-specific data formats and complex access controls.|
|Ubiq Platform||End-to-end app layer encryption||Turnkey suitable. Ubiq handles app-layer encryption end-to-end, from access controls to data storage to client libraries and encryption policy.|
|Hardware-backed secure key storage||✓||✓||✓|
|Network encryption key management and provisioning||✓||✓|
|Automatic and one click on-demand key rotation||✓||✓|
|Automatic key archival and retrieval||✓||✓|
|Simple encryption policy management and enforcement||✓|
|Dead-simple client libraries||✓|
|Usable with no prior encryption skills||✓|
|Simple, affordable, scalable billing||✓|
|Turn-key ready for application layer encryption||✓|
I’m not going to sugarcoat it; the security industry has fallen way behind the broader tech industry in the last decade in a really fundamental way. While much of the tech industry has started to pivot away from hardware and software-based solutions – which dominated the 90s and early 2000s – and towards the use of API-first SaaS services, most of the security industry has not.
Now, this reluctance to embrace a new way of delivering security outcomes means that customers are overburdened with acquiring, deploying, and managing security tools in a legacy model. A painful, not to mention expensive, way to defend against threats.
It’s time for the security industry to wake up and deliver security via APIs.
Around a decade ago, we saw the emergence of the “API economy” giving birth to (what are now) massively valuable tech companies. Stripe simplified the complex and painful world of payment processing. Twilio did the same for messaging and communications. Both simplified what would’ve taken customers and developers literally months of effort, cost, and tons of trial and error to build, down to a set of API calls and a few hours of integration work.
Yet, despite the emergence of so many API-first tech companies, the security space has yet to get into the game in a material way, with a few minor exceptions – kudos to Auth0 for being one of the first to do so. The (security) industry as a whole seems to be sticking with the hardware/software model and, to a certain extent, it’s working.
Customers are generating and storing more and more sensitive data and cyberattacks are on the rise, so they’re left with no other option but to continue to buy security software, which means stock prices continue to rise and shareholders are smiling. Meanwhile, (most) security vendors are heads down, working hard to adapt to evolving threats and haven’t lifted their heads to consider the larger shift in how customers want to consume technology.
If security vendors shifted from delivering outcomes via appliances and/or software, to delivering those same security outcomes via APIs, I believe we’d have happier customers and less effective adversaries.
Laggards being the exception, most customers don’t want to buy traditional security “tools” anymore. With network perimeters mostly eliminated and data residing in a multitude of systems and locations, the focus should be on providing customers with security outcomes in the most efficient and flexible way. And I believe that is security via API. By allowing customers to enable higher-quality, more secure experiences and controls faster, we eliminate all the pain, effort, and expense of acquiring, installing, and managing archaic hardware-based solutions. It would also potentially help close the cybersecurity skills gap (which I’ve addressed in this separate post).
Under the current software/hardware model, security experts are spread too thin trying to manage security software across the entire organization while detecting and responding to threats. But by delivering security via APIs, developers can quickly and easily build security functions directly into applications, freeing up the security team’s time to focus on higher-level strategy. By shifting security left and building it directly into the applications, it would also make applications inherently more secure.
Though we haven’t seen a massive shift in the security industry towards delivering via APIs, there are a few companies who embraced the model early on. Auth0 (which was acquired by Okta for $6.5B), is probably the best, most recent example of a truly API-first security vendor. However, there are definitely a number of big players like Cisco, FireEye, and CrowdStrike who have started to dip their toes into the API waters.
Auth0 is a fantastic example of a security company that delivered an Identity and Access Management outcome to its customers via API from day one. They recognized very early on that identity verification was an incredibly arduous and painful process, and something to get right.
“Since our inception, we’ve always believed in a single platform to solve all Identity and Access Management (IAM) requirements. We take a very different approach compared to what traditionally has been done in this industry. Developers, the "makers" of this new world, appreciate building blocks that are simple to integrate but that can adapt to different situations,” said Matias Woloski, CTO and Co-founder – Auth0.
Globally, Auth0 now authenticates and secures more than 2.5 billion logins per month for its 7,000 customers. How’s that for proof in the pudding?
Making the shift from the software/hardware model to security via API would no doubt bring a whole slew of new challenges. But it would help security practitioners (and developers) integrate critical security capabilities and controls into their applications and infrastructure more quickly and broadly, while enabling the security industry to catch up to the broader tech community.
I’d love to hear your thoughts on the security industry embracing the use of APIs. Do you think this shift will happen in the near future? Have you seen other API-first companies emerging to drive this change? Let's chat.
For the last 5-10 years, we’ve all heard a lot of talk about the global shortage of cybersecurity talent. It’s an issue that’s plagued the industry for years, and according to (ISC)², a nonprofit for information security leaders, the security industry would need more than 3 million skilled professionals to close the skills gap. That’s a whole lotta people.
The shortage is due to a variety of factors, ranging from a lack of advanced skills to a limited number of professionals entering the field in the first place. And the expanding threat landscape only exacerbates the problem. Qualified security professionals are spread too thin, and turnover is high at companies across the board from tech start-ups to corporations to government agencies. Also, most security teams spend more time managing security tools than actually hunting and eradicating adversaries, which is caused by the archaic way security vendors continue to deliver security outcomes (via hardware and software), which I’ve covered in this post: [insert title and link]
Before we address the question, it’s important to walk through why variations of (really) the same two training-oriented solutions the industry continues to push, aren’t working.
These low-and-slow solutions have major flaws – they take too long and we’re simply “training” more people to become defenders. I think there is a far more efficient and effective way to slow down the attackers and reduce the need for millions of new cybersecurity resources.
A few obvious points I’d like to make. Today, most security vendors sell hardware and software-based solutions, which are then operated by a company’s security or network team team or a third-party managed service. At the end of the day, these solutions are used to detect, prevent, (or whatever other buzzword is trending) hackers from doing nefarious things. “Nefarious things,” in most cases, involves exploiting software vulnerabilities.
Call me crazy, but if most adversaries are exploiting software vulnerabilities, wouldn’t it make sense for us (the security industry) to focus more of our time and attention on improving and enabling the security of the applications?
And wait…while there are only (roughly) 3.5 million cybersecurity professionals worldwide, there are exponentially more software developers – approximately 86 million on just Github and Gitlab alone, as of the writing of this article. I think it’s safe to assume software developers also have a vested interest in protecting the software they’ve built.
So rather than trying to recruit and train millions of new cybersecurity experts, what if we also enable the existing population of software developers to build security controls directly into their products via APIs, without having to become security experts?
For the most part, the tech world has embraced the use of APIs. Look no farther than Stripe and Twilio for shining examples of that. But the security industry is lagging way, way behind. If security vendors start building API-based security tools for developers rather than purely for security professionals, it would eliminate some of the responsibilities from overworked security teams and shifts security left to the massive population of developers who are already familiar with APIs. This would free up security teams to work on higher-level strategy and (bonus) it would result in more secure applications.
I’m by no means suggesting that we shouldn’t develop more security talent – we should. I’m simply suggesting that the security industry deliver solutions that can be integrated directly into applications, enabling customers – and tens of millions of developers around the world – to integrate security directly into their products.
Yes, this would require a massive mindset shift and more API-first security solutions, but I believe it will curb the impossible-to-fulfill demand for security professionals, by enabling a far larger population of software developers to join the fight against evil and build more secure applications.
Congratulations, you just completed final coding for a new stock tracking app and you’re ready to release it into the market. Your users will be able to specify which stocks and how many shares they own and set alerts when certain price targets are reached. For real-time stock prices, your application connects to a third-party service that updates the app’s UI with the user’s total investment.
Up until now, you probably haven’t put too much thought into encryption. Your app is pretty simple and doesn’t require the user to set up an account, so no personal information is being sent anywhere. Plus, you’re using local storage to record stock names, number of shares, and price targets.
Yet, if the phone was hacked, your app would hand the hacker the information they need to piece together a larger attack strategy. For example, if your app reveals that the user is monitoring 1,000 shares of Tesla stock, the hacker may conclude that the user probably owns that many shares, and the hacker could launch a secondary attack. Even the name of the investment provides useful information. Hackers have been known to infiltrate quietly and stay inside a system for weeks or months as they gather seemingly innocuous information. A recent example was the massive attack carried out through malicious code inserted into the SolarWinds software. It is believed hackers spent months infiltrating networks before they were detected.
So, you may think your app isn’t storing anything important and therefore skip encryption, but any data a user enters into an app can be used as a puzzle piece to aid in larger infiltrations. This is exactly what hackers hope for.
So, whose responsibility is it to secure customer data? The truth is it’s a shared responsibility. Everyone involved with the application must take the necessary steps to protect the data you have control over.
Think of a conveyor belt moving data from station to station. If you encrypt the data at your station and it moves on to the next station only to be decrypted and left out in the open, that’s where the hacker will go.
Consider the basic stock tracking application. You make assumptions that the app delivery from the Apple app store or Google Play is secure and that the app is not altered along the way. You also make assumptions that the person using your app is properly authenticated and logged into the phone. Finally, you make assumptions that the external services, such as the stock price service, is secure and not exposing your users’ information. That’s a lot of assumptions and you’re heavily relying on other parties to keep your users’ data from leaking out. As a developer, you need to take a more proactive approach to data security.
Even if you believe your application isn’t dealing with sensitive data, a more critical look could unveil potential security problems. As a start, you may want to treat any data within your application as sensitive data. You must take full responsibility for encrypting app data because your users are expecting you to protect their data.
Let’s say you want to increase the security of your stock tracker app and make it more difficult for a casual hacker to see user-entered data such as stock names, number of shares, etc. You could move the persistent data storage from local storage to the device’s encrypted key chain. Alternatively, you could use an encrypted cloud service to store that data remotely. Both options are a good start but have pros and cons. If a hacker gets access to a single password, the user’s encrypted data is no longer safe.
Taking responsibility for protecting user data should be central to your development process by taking a “secure-by-design” approach, meaning security is designed into the application from the beginning. This does not mean you need to take a course on advanced cryptography or figure out how to write your own encryption routines. In fact, you shouldn’t roll your own encryption algorithms or try to obfuscate data you want to protect. Assume attackers have access to your source code. Do not hope to rely on some proprietary algorithm to keep your data safe.
Most platforms you are developing for have well-tested encryption libraries available. For Android, you’ll find cryptographic facilities and a keystore system. Similarly, for iOS, you’ll find crypto Swift libraries and a keychain mechanism available. Certainly, with most existing methods, it can take some effort to learn how to use these libraries and you may end up with many more lines of code to support them.
The Ubiq API-based Platform, however, is designed to help developers avoid the complexity and mistakes related to data encryption when building applications. Ubiq constantly monitors the latest research related to cryptographic algorithms, including encryption and hashing, as well as any newly discovered vulnerabilities, and it incorporates the newest information into the platform, ensuring your data remains as secure as possible.
To learn more about how the Ubiq platform helps developers build more secure applications, watch our short demo video.
Cryptographic functionality is essential to a massive number of applications. As data protection regulations mandate how certain types of data should be protected, developers are increasingly required to build cryptography into their code. Java is currently one of the most popular programming languages used across a wide range of applications including Minecraft and Hadoop, so it’s important that developers know what to consider when implementing cryptography correctly.
However, cryptography can be complicated, and most developers are not secretly cryptographers on the side. Requiring developers to jump through hoops and blindly make crucial decisions is not a good or safe way to implement core security functionality.
Cryptography can go wrong in a number of different ways. By making mistakes or trying to take shortcuts, a developer can easily undermine the security of the application they are writing and the data that it uses.
But let us assume a developer is not trying to work around the rules or develop a custom protocol. How hard is it to implement cryptographic functionality and what can go wrong? Implementing a “simple” function using cryptography requires working through the following process.
“Rolling your own crypto” is never a good idea due to the large number of ways in which it can go wrong. It is always better to select an existing library rather than attempting to write the cryptographic code yourself.
However, selecting a library can be a challenge for a developer with limited knowledge of cryptography. Important considerations include:
Many programming languages have built-in cryptography libraries, and a number of third-party libraries exist as well. Without in-depth knowledge of cryptography and these libraries, it may be difficult to determine if the selected library is the best choice for a developer’s use case.
Solving this challenge can be especially difficult in Java due to how Java’s cryptographic providers work. Unless a developer specifies the implementation of a particular function that they want to use, Java will automatically select the first provider that offers that functionality. This means that a developer may not know the implementation used by their code or how secure or optimized it is.
After selecting a library, it may be necessary to configure it. Some libraries may be designed to be standalone or to automatically install any required dependencies. Other options may have functionality enabled or disabled based upon whether or not the required dependencies are installed.
Depending on the quality of the documentation and the installer used, it may be difficult to determine whether or not a cryptographic library is correctly installed and configured. This has the potential to impact the security and usability of the code relying upon the library.
Encryption algorithms can be classified in a number of different ways, and each category has its advantages and disadvantages. For example, asymmetric encryption is ideal for setting up a key exchange but is inefficient for bulk encryption, while symmetric encryption is much more efficient but requires a pre-shared key.
Selecting which encryption cipher is best suited for a particular use case can be confusing. There are several ciphers other than Advanced Encryption Standard (AES), including Salsa20, 3DES and Blowfish but AES is the NIST standard, so it’s commonly chosen.
Once an algorithm has been selected, the next step is to properly configure it. Many encryption algorithms and use cases have certain requirements and additional choices, such as:
These are only some of the decisions that a developer may need to make when implementing cryptography for a particular application. Whether or not the right decisions are made can depend heavily on the developer’s knowledge and the quality of the library’s documentation; however, research has determined that poor documentation is a common complaint and leading challenge faced by Java developers.
When working with cryptography, many developers take an “error driven” approach to working with the API. With this approach, whether or not the code is “right” or “wrong” depends solely on if it compiles without errors.
Java cryptography libraries are known to have unclear error messages that do not help developers to solve issues in their code. Without a usable system and clear documentation, the security of a developer’s code may depend on luck and which page they reference on StackOverflow. Implementing cryptography correctly requires an interface that makes it easy for the developer to do the right thing.
Cryptography can be complicated, and even little mistakes can have significant impacts. For many of the applications built in a language such as Java, where cryptography is used, these little mistakes can be the difference between a secure system and an embarrassing data breach.
Ubiq is designed to make using cryptography simple for developers by eliminating many of the decisions and challenges that they face when implementing cryptographic functionality. By handling the complex functionality behind the scenes and only exposing a simple API, Ubiq eliminates the opportunity to make these costly mistakes. To find out more about how to quickly build data encryption into any application, watch our short demo video.