Archive for February, 2006

Uncategorized Analyzing the pentium stack part 1

0 Comments

How does a Pentium stack works

The purpose of this article is to explain very briefly what is a pentium stack. The reader, in order to understand the content of this article, must have a basic knowledge of how processes do memory management (e.g. segmentation), have a basic knowledge of assembly and C.

For this article I have used the following software and hardware:

  • GNU gdb 6.1
  • GNU gcc 3.4.6 (for the series of 2.4.x)
  • Suse 9.1 (with a patched kernel)
  • Perl 5.8
  • ANCI C
  • Aspire 2001WLCI (with Intel Centrino Mobile Technology)
For this article I have used the following notation:
  1. For command prompt input (keyboard typing): Grey color is used
  2. For command prompt output (stdout): Italik font is used
  3. For code:Parple and light blue colors is used
Assumptions made in this article:
  • Use a root terminal (super user) for your convenience
  • The system I used does not have exec-shield technology (used in later builds such as Fedora ….)

Stack Structure

A stack is a first in, last out (the well known FILO) data memory structure used to load, or in other words to allocate space for the user or operating system processes. Now in order to manipulate the stack you need to know three different stack pointers (this is a very simplistic approach):

  1. EIP (Extended Instruction pointer)
  2. ESP (Extended Stack pointer)
  3. EBP (Extended Base pointer)

The EBP is used to show the base of the stack, in other words the beginning of the stack, and is static, meanning once allocated never changes. The fact that EBP is static makes stacks ideal for writing buffer overflows (e.g. Heaps are much more difficalt to corrupt!!). ESP is not static, which means that it’s values change through the time and it shows always the end of the stack (the stack shrinks and grows from the ESP). The most imortant of all pointers is EIP, because EIP is points the register address for all function calls related with the current stack. If someone can locate EIP then this would give him the opportunity to execute his/her code!!!

Stack structure: esp < ----> ebp < ----> eip

How does a stack look like in assembly

Initially we will compile and run simple programms in C, use gdb to disassmble the main function, and see how the main function looks in assembly

Step 1: Write and compile a simple main function:

int main(){;} //This will allocate a stack to run our main

Step 2: Use gcc to set a dword (meanning to use double words of 16bits long instead of 32 bits long) to make things simpler

# gcc -mpreferred-stack-boundary=2 -ggdb t.c -o t

Step 3: Disassemble only the main function with no parameters or functions

# gdb t

GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i586-suse-linux”…Using host libthread_db library “/lib/tls/libthread_db.so.1″.

(gdb) disas main
Dump of assembler code for function main:
0×0804835c : push %ebp
0×0804835d : mov %esp,%ebp
0×0804835f : pop %ebp
0×08048360 : ret
End of assembler dump.
(gdb) q


Explanation: The extended base pointer (ebp) is pushed into the stack and then it is copied on the extended stack pointer (esp). The push assemby command is used to insert data on top of the stack (a FIFO stack starting from ebp and ending at esp) while the mov assembly command is used to copy the a source (ebp) to the a destination address (esp).

In our example ebp becomes equal to esp (more simply ebp becomes a copy of esp). Now because ebp and esp do define the limits of the stack it is logical to assume that the stack is empty. The esp always points to the top of the stack (the higher address) and decrements or increments (depending whether the data are pushed or poped), from the lowest address.

The pop command is used to pop data off the stack. In our example exactly because the stack is empty esp becames equal to ebp and then gets poped off the stack. After having esp poped off the stack our process is terminated by calling the ret command. The ret assembly command is used to return the execution flow, and? terminate the current? procedure.

Step4:Now we move to something more complicated

int main(){int a;} //This will allocate a stack running main

Step5:Use gdb to see the assemply

(gdb) disas main
Dump of assembler code for function main:
0×0804835c : push %ebp
0×0804835d : mov %esp,%ebp
0×0804835f : sub $0×4,%esp
0×08048362 : leave
0×08048363 : ret
End of assembler dump.
(gdb) q

Explanation: Variable a is compiled but not initialized in the code example above. The last two assembly lines and are used to clean the stack (leave and ret). Again because our stack is empty esp is copied to the ebp.

The sub command is again used to subtract the source from the destination (this time the source is the esp and the destination is 0×4) and store the result in the destination (meanning the 0×4). The leave assembly command is used to load the effective address of the source to the destination, but because our code does not do anything and contains no data, the line remains empty.

Step6:Now we move to something even more complicated

int main(){int a=0;} //This will allocate a stack running main

(gdb) disas main
Dump of assembler code for function main:
0×0804835c : push %ebp
0×0804835d : mov %esp,%ebp
0×0804835f : sub $0×4,%esp
0×08048362 : movl $0×0,0xfffffffc(%ebp)
0×08048369 : leave
0×0804836a : ret
End of assembler dump.
(gdb) q

Explanation: Everything is like the example in step 5, but this time the variable a is initialized. The value we used to initialized the a variable is 0 and in hexadecimal is represented with $0×0, now the the 0xfffffffc value shows the register address that the true value was placed.

Refrences:

http://webster.cs.ucr.edu?

Uncategorized Public Key Info-structure in SMIME/SMTP

0 Comments

Does ANYBODY know exactly how PKI is used in SMIME?

SMIME is a de facto standard created from RSA security Inc. and also one of the most (if not the most) used standard for secure message exchanging, now days. Yet you still can?€™t easily find information about SMIME that explain in simple words how it works!

For the purposes of this article I am going to use the following terms:

  • CSM = Clear Signed messag
  • OSM = Opaque Signed Message
  • ECSM = Encrypted Clear Signed message
  • EOSM= Encrypted Opaque Signed message
  • CA = Certification Authority
  • CRL = Certificate Revocation List
  • CEK = Content Encryption Key
  • KEK = Key Encryption
  • SK = Session Key
  • PEK = Public Encryption key (RSA)
  • PSK = Public Signing Key (RSA)

Through out this article I will assume that the reader is capable of understanding the terms mentioned above!

How to e-mail clients communicate securly

Two e-mail clients (e.g. Outlook 2003 or Outlook Express 6.0) that support SMIME standards can communicate in a secure way if:

1. Each client has some sort of access to a Certificate repository (a certificate database)
2. Both clients can connect to a functional SMTP server (both client can sent and receive plain text messages)

Client A < —-> SMTP Server < —-> Client B
| |
| |
| |
| Certificate B (Certificate Repository)
|
|
Certificate A (Certificate Repository)

By using the term Certificate Repository I mean that the e-mail client has access to the relevant certificates by:

1. Using an LDAP server with stored certificates
2. Using the appropriate certificate services from the operating system to extract the certificates (e.g. Microsoft Certificate Services)
3. Using online certificate services provided from the a CA (e.g Verisign)

With SMIME we have four basic possibilities

A. If Client A wants to sent a CSM to Client B then:

1. A needs a Certificate A that contains his/her e-mail address into the Alternative Subject Name
2. B?€™s e-mail client does not have to support SMIME in order to see A?€™s message (but he/she won?€™t be able to verify A?€™s signature)

B.If Client A wants to sent an OSM to Client B then:

1. A needs a Certificate A that contains his/her e-mail address into the Alternative Subject Name
2. B e-mail client does need to support SMIME in order to see or verify A?€™s message

C.If Client A wants to sent a ECSM to Client B then:

1. A needs a Certificate A that contains his/her e-mail address into the Alternative Subject Name
2. A needs a Certificate B with that contains an e-mail address into the Alternative Subject Name with B?€™s name (meaning an e-mail address that represents B and is used in the SMTP header in the field To: ?€¦..)
3. B does need to support SMIME in order to see, verify and decrypt A?€™s message

D.If Client A wants to sent a EOSM to Client B then:

1. A needs a Certificate A that contains his/her e-mail address into the Alternative Subject Name field
2. A needs a Certificate B with that contains an e-mail address into the Alternative Subject Name with B?€™s name (meaning an e-mail address that represents B and is used in the SMTP header in the field To: ?€¦..)
3. B does need to support SMIME in order to see, verify and decrypt A?€™s message

The SMIME PKI for dummies

Now lets see exactly how an e-mail client is using PKI and SMIME standards. If we analyse possibility C, we will see that unless we have a good undestanding of SMIME there is no obvious reason for A to use B certificate. In the example explained below I assume that the following algorithms were used: RSA with SHA1 or MD5 and any symmetric algorithm.
Step 1. A’s e-mail client encrypts the content of the message (the data) with a key called SK produced from the e-mail client. If the e-mail client does not use a good random key generator process then the the SK is not a very random session key (temporery key) and not a secure one.

SK(CONTENT)

Step 2. A’s e-mail client encrypts the SK with a key called KEK found in B’s certificate (B’s RSA public encryption key)

SK = CEK and KEK = B’s public RSA encryption key

Step 3. Now A’s e-mail client uses Certificate A to sign the message (using A’s RSA private signing key)

ENCRYPTED SMIME OBJECT = KEK(CEK)+CEK(CONTENT)

SIGNGNATURE SMIME OBJECT = PSK(ENCRYPTION SMIME OBJECT)

FINAL MESSAGE = SMTP HEADER + SIGNGNATURE SMIME OBJECT

References:

[1] SMIME with Exchange

[2] Sendmail Home

Uncategorized Smart Card multi-application platforms

0 Comments

Smart Card multi-application platforms todays

?€?Smart Card multi-application capabilities allow multiple applications to reside on the same platform (meaning the same smart card chip) with the guarantee that applications do not interfere with one another. This means that data that are private to one application should remain private and other applications can not read or even modify these data?€[1].

Multi-application smart cards helped businesses to evolve and expand not only their products but also their services in changing the global marketplace. The scope of uses for a smart card expands each year to include applications in a variety of markets and disciplines. Today?€™s information age has introduced a huge amount of security and privacy issues that are calling for the advanced features of the smart card secure multi application platforms.

Smart cards characteristics such as tamper resistance (meaning tamper proof hardware), portability and dynamic application management, the term dynamic application management, refers to the ability of the platform to allow the issuer of the smart card to update the smart card once it is in the field, made it a technology well suited for hosting multi-partner smart card programs. By using the term multi-partner we mean the ability to share the control in one smart card with many issuers. At this point it should be clear that the term issuer is used to describe the controlling authority and not the card holder.

Some of the major smart card uses are:

  • E-Banking transactions
  • Mandatory access control
  • Identification/Authorization
  • Ticketing

Smart card multiple application operating systems enabled more than one issuer to have limited control over the same
smart card in a very smooth, clear and functional way [1].

Java-Card a multi-application platform

Java Card is a relatively new but also very fast growing technology that enhances the world of smart cards with a whole set of new and interesting features. Until a few years ago all smart card vendors had their own specific proprietary operating systems to run their applications. The term proprietary operating system is used to describe smart card operating systems that have the sufficient security level for running the also appropriate smart card software, (e.g. game smart card programs do not have same security profile as e-payment smart card programs).

The result was that all smart card programmers had to face many difficulties in order to get their applications to run on multiple platforms. Due to the success of Java in the desktop world, as a language and as a platform it seemed to be an attractive idea to design a small java-based operating system/platform that would run either on top of many different smart card operating systems or even as a stand alone operating system on top of the smart card chip. Collaboration between SUN and a group of card manufacturers resulted into the birth of Java Card technology in 1997.

“The most popular properties of Java Card technology are:

  • Interoperability: Verified applets run on every Java Card enabled chip.
  • Multi-application features: Multiple applets can coexist.
  • Dynamic application management: New applets can be added post-issuance.
  • Secure features: Java inherent security is enhanced with dedicated concepts” [2].

Today is world wide accepted that Java Card is a technological breakthrough. Large quantities of newly produced smart cards are Java Card enabled, and card issuers start using the possibilities offered by this technology.

Refrences

[1] Peter Johannes, Chip Programme ?€“ MAOS Platforms, 10 April 2000, date retrieved on: 22-06-2005

URL: http://www.multos.com/library/pdf/00-04-10%20Europay-maos-report.pdf

[2] Mark Witteman, Java Card security,date retrieved on: October 2003, 12-06-05

URL: http://www.riscure.com/articles/ISB0808MW.pdf

Uncategorized Smart Card operating system evolution…

0 Comments

Smartcard operating systems history

?€?The smart card’s Chip Operating System (frequently referred to simply as COS; and sometimes referred to as the Mask) is a sequence of instructions, permanently embedded in the ROM of the smart card. Like the familiar PC DOS or Windows Operating System, COS instructions are not dependent on any particular application, but are frequently used by most applications?€[2].

The history of the smart card operating systems is closely related to the evolution of the smart card chips (ICC), they were designed for. In the mid of the 1980?€™s [3], a typical smart card had 6 Kbytes of ROM, 128 bytes of RAM and 3 Kbytes of EEPROM. Thus programs written in low level language were constructed directly upon the hardware (ICC) of the smart card. This was the main reason why these functions were typically included into libraries, to prevent programmers from writing every application from the beginning. During the years more functions were added to these libraries that were of course optimized to the properties of a specific micro-controller each time. This library orientated approach is known as the first generation of smart card operating systems [3]. The libraries containing the functions were burned into the ROM in order to provide the basic functionality to the smart card operating system, so the libraries remained the same until the card termination.

Multi-application operating systems

The need of the market for open and global standardization, but also for higher compatibility, modularity and hardware independency led to further evolution of the smart card operating systems, the so called third generation chip operating systems. The demand for more resources in third generation operating systems also helped to evolve chip capabilities (e.g. increase computing power).

In third generation operating systems the concept of modular layered architecture was introduced. The goals of layered operating systems are modularity and portability. In the layered approach the whole functionality of the hardware (meaning the ICC) is not used directly but encapsulated by a layer located directly above the physical layer. This layer provides a well specified hardware independent interface to the above lying layers (HAL) [3]; dynamic application loading now became easy since less information is needed to describe the technical features of the card.

In third generation operating systems two software technologies prevailed, the multi-function operating systems (GeldKarte, Chipper, MFC) and multi-application operating systems. Multi-function systems allow multiple applications to run on the same software platform, but without the guarantee that the applications will not interfere with one another. Multi-function platforms that are based on platform specific executable code are referred to as MFC platforms [1]. No application isolation is achieved in this model. A multi-application operating system allows multiple applications to run on the same software platform, but with the guarantee that applications do not interfere with one another.

Application independence or waterproofing can be achieved with two ways:

1. Interpreter: The application code is compiled into a byte code file and afterwards it converts to a more appropriate format so as to be executed by the proprietary platform. The interpreter is now responsible to verify the application code in order to eliminate the risk of letting the application to perform maliciously.

2. Memory manager: The memory manager checks each memory address to see if the application performs prohibited memory reading, with the use of boundary registers. The term bound registers refers to the registers that are used are limits.

Monolithic versus Multi-application platforms

Monolithic-application platforms are burned into ROM during the smart card fabrication stage, the operating system along with the vendor application are masked all together. Monolithic platforms are not flexible, do not support more than one application, and are hard to maintain.

Multi-application platforms now days have prevailed for obvious such as platform portability, software modularity, application isolation and hardware independency this are the key characteristics for multi-application platforms success.

The smartcard multi-application platforms

The most attractive feature in a multi-application platform is the dynamic application management. The term dynamic application management refers to the ability of the platform to allow the controlling authority of the card to update the card once it is in the field [1]. To be more specific when using the term dynamic application management, we mean the execution, locking, unlocking, and deleting of card applications software remotely in a well formed and secure manner. Because of this feature lots of security issues arise, such

1.WfSC

In the summer of 1998, Microsoft has launched a new business unit promoting a chip card OS, named ?€?Windows for Smart Cards?€™ (WFSC) [1]. The operating system is masked put into ROM during the fabrication stage of the SC while the applications are also masked into the ROM or loaded into the EEPROM. Dynamic application management is available in the WFSC platform. The issuer has to define his own security mechanisms for the card management. The availability of the complete version 1.0 specification is imminent. Only a part of the version 1.0 specification is available [1]. As application development tools the existing Visual Basic software development kit will can be used there id going also some support for C API?€™s.

2.Multos

MULTOS is a secure operating system which has been specifically designed for SC systems [1]. MULTOS platform makes use of the MEL VM along with the operating system. Dynamic application management is also available in MULTOS platform. Waterproofing between the applications is guaranteed by the kernel. This means that the applications do not need to be certified. Current implementations of MULTOS platform use an 8 bit CPU along with a cryptographic co-processor (in order to perform RSA calculations). The memory requirements are 4K for the Virtual Machine, 7K for the executive and 7K for the libraries. (including EMV functionality) 7K.

3.Java-card

Java Card is an operating system also designed for SC systems. A software implementation of the Java Card VM on an 8 bit CPU yields about 3000 instructions per second [1]. This has an impact on application execution speed (Java Card applications are much slower than C applications). The Java Card VM is based on an open specification, which is controlled by SUN Microsystems (Open Platform). Java Card applications do not need to be certified since the VM guarantees waterproofing between applications (through the use of Java card sand box model). More details about the Java Card platform will follow in the next chapter.

Refrences:

[1]

Peter Johannes, Chip Programme ?€“ MAOS Platforms, 10 April 2000, date retrieved: 22-06-2005
URL: http://www.multos.com/library/pdf/00-04-10%20Europay-maos-report.pdf

[2]

Jacquinot Consulting, Inc, What is the COS?, July 20 2005, date retrieved: 30-07-2005
URL: http://www.cardwerk.com/smartcards/smartcard_operatingsystems.aspx

[3]

Felix Pletzer, Architecture of a portable Smart Card Operating System, 17-May-2004, date retrieved: 19-07-2005
URL:http://www.iaik.tu-graz.ac.at/teaching/10_seminare-projekte/01_Telematik%20Bakkalaureat/Seminararbeit_Pletzer.pdf