Tech in the vein: Cryptography and secure development

At Invillia, every Wednesday at noon, we stop for an hour to nourish ourselves with the tips, how-tos, good practices and trends selected by our specialists in Product, Agile, Back and Front, Mobile, Quality, Security and Data. A vital exchange of experiences for those who love the new. And essential for innovation to never stop. If technology is in the blood. We make sure to keep it circulating more and more_

IN THE VEIN_ Encryption as the new normal_
5-minute read

We leave here the main learnings of the edition presented by Alexandre Braga, a security specialist, including some insights from his paper [PT].

The concept

Cryptography (from the Greek kryptos, meaning hidden) is the only technology capable of guaranteeing the confidentiality, authenticity, integrity and irrefutability of information in transit by electronic means:

Confidentiality is obtained to keep information secret, confidential. Sending encrypted emails and keeping encrypted files are examples of confidentiality.
Authentication is obtained to validate an entity’s identity. An example is a digital signature to verify the authorship of an electronic document.
Integrity is achieved to ensure that a portion of data has not been modified since its creation. Error detection codes are examples of mechanisms for checking data integrity.
Irrefutability is obtained as a means of ensuring that the author of an authentic message cannot deny its authorship to a third party.

In practice, these services are used together. For example, an e-mail message can be encrypted and digitally signed. In this way, both confidentiality and authentication will be guaranteed. Since the digital signature is unique to the message, integrity is also preserved.

The cryptographic system

The image below shows a cryptographic system and its fundamental elements. Three characters illustrate the figure: Ana, the sender of the messages; Beto, the recipient of the messages; and Ivo, the opponent with a desire to know the secrets of Ana and Beto. The messages pass through an insecure communication channel controlled by Ivo. The cryptographic algorithm is used to transform the plain text (readable by anyone) into encrypted text (the cryptogram readable only by Ana and Beto) and vice versa.

The cryptographic key is the parameter for configuring the algorithm that makes it possible to recover clear text from encrypted text. Ana and Beto use a cryptographic key known only to them and shared (or combined) by a differentiated secure channel. Theoretically, it is said that the security of the cryptographic system resides in the secret of the key and not in the secret of the cryptographic algorithm. Roughly speaking, when using a reputable algorithm, the quality of the implementation of this algorithm and the size of the key determine the difficulty in breaking the encryption of the message. The Figure has the following steps:

Ana configures the encryption algorithm with the key shared with Beto;
Ana passes the clear text to the algorithm and obtains the cryptogram;
The cryptogram is transmitted over the insecure channel and received by Beto;
Beto sets up the decryption algorithm with the key shared with Ana;
Beto decrypts the received cryptogram and obtains the original clear text.

The types of cryptographic systems

There are two types of cryptographic systems, known as secret key (or symmetric) encryption and public key (or asymmetric) encryption. In secret key cryptography, a single key is used to encrypt and decrypt information. In public key cryptography, two keys are required. A key is used to encrypt; the other, different key, is used to decrypt the information. These two keys are mathematically related and work in pairs, so the cryptogram generated with one key must be decrypted by the other key in the pair. Each key reverses the work of the other and none can be used alone in a cryptographic system. In public key systems, one of the keys in the pair is said to be private (the decryption key), the other is made public (the encryption key).

The cryptographic software project standard

The image below shows the class diagram, in UML, of a symmetric cryptographic system for secrecy, in which Ana encrypts and Beto decrypts. Ana and Beto use encryption through an application (App), in different instantiations, AnaApp and BetoApp, respectively. The App has a class with a controller stereotype (CriptoCtrl) that is responsible for orchestrating cryptographic services and configuring security parameters along with the application logic. For example, in the case of Ana, CriptoCtrl formats the message m in a format suitable for encryption, encrypts the clear text tc with the key ke and makes Beto receive the cryptogram c. Beto, in turn, uses his cryptographic orchestrator to decrypt c with the kd key and convert the clear text tc to the required formatting m. Ana and Beto use different instances of the same Algorithm (cryptographic) class.

The cryptography and the programmer

“I don’t like cryptography, but I have to use it. And now?” is a phrase that is heard a lot from programmers because in the past it was done more in the infrastructure and less in the application. But that has changed radically. The most popular cryptographic software is applications with encryption in the business logic. The correct use of encryption in the application is no longer an infrastructure problem, it is not solved only with TLS and it is not just https.

More and more companies that have strict security requirements make this possible via encryption. For example, in electronic payment applications. All FinTechs need to invent business logic by mixing cryptography within the logic of the application.

That is why cryptographic software is becoming more and more common. You have it, use it or make it. In a search of your favorite app store, you will find lots of software that declares itself to be cryptographic. And then the problems begin.

Misuse

Misuse of cryptography is all too frequent. Development teams are not necessarily trained in security and much less in cryptography. There are several studies that prove that most of the application vulnerabilities associated with cryptography are related to its use and not to problems with the implementation of the algorithm. It is not the insecurity of mathematics, it is not the insecurity of the algorithm, it is not the insecurity of the library, it is the way it is used:

OJC – Oracle Java Cryptography | GAD, GASD – Google Android Developers / Security Discussions

And the big question is that the misuse continues over time. Because everything is dynamic and changing. The “rice and beans” in cryptography is good, but not enough:

Avoid weak or obsolete encryption
- DES, 3DES, RC4, MD5, MD2, SHA-1
Avoid insecure key sizes
- <2048 for RSA
- <2048 for DH
- < 128 for symmetric encryption
- < 256 for hashes (output size)
- < 256 for ECC

The source code

Since “rice and beans” are not enough, we must start with what matters most, which is the source code. In an adaptation of Mafalda’s famous phrase: Living without reading source code is dangerous. It forces you to believe what they say.

For a practical view, visit https://bitbucket.org/alexmbraga/crypto4developers (mc-2019 folders and tutorial) from our expert Alexandre Braga with a Java cryptographic API, which complements the 3 chapters of his book:

Conclusion

Cryptography is no longer just an infrastructure problem. Cryptography is a development problem. And at Invillia we are well aware of that. To ensure that the innovations we co-create with game-changers from the most advanced industries are secure right from the start. Where the priority is prevention and not reaction.

Let’s develop your next super secure app together. Fintech, Regtech, Govtech, Biotech, Healthtech, Agritech, Mediatech, Hometech, Edtech, Anytech_ count on us_