Posted by davitb on 10th November 2009
In my previous article I was discussing how a “non expert” security engineer should think about choosing the right security protocol for his system. I have tried to present that complicated task in an easier manner.
However it’s important to also understand that when we integrate a secret based protocol in our system, we will get another, more serious problem – how to securely hide the secret that is used in the protocol for authentication?
For example, suppose you have two components which are establishing an SSL protocol. As SSL is based on public key cryptography they both need to possess private keys (if the authentication is mutual). So how are they going to protect their private keys locally in their systems?
Of course the problem of hiding cryptographic keys or other secret information doesn’t only apply to systems which are implementing security protocols. Encryption is the most popular and convenient way to protect the confidentiality of information. However when the system encrypts something there should be a way to protect the encryption key (or the decryption key) and this, believe me, is a much, much harder problem.
In this article we will discuss the ways how one can hide secret information in:
- Windows environment
- Inside a software
- Inside a hardware
I have been doing research on this topic more than a year now and would like to share my knowledge and experience with you.
All the mentioned topics are heavy and one cannot describe all of them in a single article. I’m planning to have several articles describing different aspects of these themes (such as obfuscation and tamper-proofing in software, tamper resistance in hardware, etc).
So in this article we will discuss the “theoretical” part of the topic and then will go through an example and try to apply this knowledge in real life.
Read the rest of this entry »
Tags: confidentiality, CryptProtectData, CryptProtectMemory, hardware protection, obfuscation, tamper proofing, TPM
Posted in how to design secure systems?, software obfuscation, tamperproof software | No Comments »
Posted by davitb on 2nd November 2009
We all know that sending data over network and being sure that its confidentiality is not damaged is one of the crucial problems in security engineering. In fact, except some special cases the entire information security area is based on the problem of being able to send information from point A to point B and making sure that’s its security properties are maintained properly.
Creating secure protocols is not an easy task and this article is not intended to help you to create new protocols from the scratch. There already exist many well designed protocols which will give you all the necessary features to meet your requirements. There are many books and articles about how different secure protocols work and how they are designed. This article is not trying to describe details of these protocols rather it tries to recommend the “ideal” protocol for you, which of course doesn’t exist. The question that this article will try to answer is how you should choose the right secure protocol for your particular application.
Choosing the right protocol is also not a trivial task however I believe there are patterns which will help you to solve this task for your particular application. I’m able to recognize these patterns and I’m sure you will also be able to do it once you get the proper knowledge and experience.
We will go over the following topics:
- Data confidentiality and integrity in protocols
- Two types of security protocols
- Attacks you should worry about while thinking about protocols
- Protocol Choosing Patterns
- A demonstrative example
- Recommended references
Read the rest of this entry »
Tags: authentication, authenticity, confidentiality, diffie-helman, eavesdropping, integrity, man-in-the-middle, replay attacks, security protocols, SPEKE, SSL
Posted in Attacking secure systems, authentication, how to design secure systems? | No Comments »
Posted by davitb on 28th October 2009
Before starting discussing different techniques which are helpful while creating architecture of a secure system, it’s useful to go through the key concepts which must always be at primary concern of any software/hardware architect while thinking about security.
In this article we will go through the key concepts in information security and will try to explain them by bringing real life examples. Throughout the article I will also call the key concepts “security properties” of information.
So the security properties we will discuss here are:
- Confidentiality
- Integrity
- Authenticity
- Availability
- Non-Repudiation
- Accessibility
Read the rest of this entry »
Tags: accessibility, authenticity, availability, confidentiality, integrity, non-repudiation
Posted in how to design secure systems? | 1 Comment »
Posted by davitb on 19th October 2009
Secure system is a piece, or any combination of hardware, software or just an operation which protects an information block that is sensitive to the user. There are secure systems which are dedicated to perform only security related operations (such as safe storage, a dongle token, DRM system, firewalls, encryption device, etc). There are also systems which are designed to perform operations which work on sensitive information and thus require having security features implemented inside (such as online payment systems, ATMs, email clients/servers, messengers, etc). Independent of purpose of the system and the operations it allows to perform – the security engineers must threat them identically important and design the security of these systems by taking into account the state of art best practices and techniques.
This article is the first part of a series of articles dedicated to principles and best practices of designing secure systems. It will discuss the following topics:
- The wrong approach of designing security systems
- The right approach
- Assets, threats, security controls, vulnerabilities, attack vectors and risks
Read the rest of this entry »
Tags: attack graph, attack vector, risk, security design, threat, vulnerabilities
Posted in Attacking secure systems, how to design secure systems? | 1 Comment »