Final report

Mobile Email Client Security

Team-9

Anirudh Gaur (B.Tech)

Rahul Sihag (B.Tech)

Bharatram Natarajan (M.Tech)

Sanjay Bankapur (M.Tech)

Challenge 1:

Identify and specify various security requirements. You can choose to specify them as abuse

or misuse cases along with use case descriptions for the same. Whatever method you choose

for specification, the requirements should be correct, unambiguous, verifiable and consistent

at the least.

Solution:

We have listed the Use/Abuse case for Mobile Email Client (MEC)

Use Case1: User tries to login to MEC with Local Credentials.

Use Case2: User clicks on Synchronous button to synchronise between Email Client and

Email server.

Use Case3: User clicks on Send/Receive button to send the mail from client to server and

receive mails from server to client.

Use Case4: User can create folder structure at Email Client to bifurcate the mails according

to the needs and can give permissions like read, write execute for folders.

Abuse Case1: Malicious Program which is running in mobile device will capture the Local

Login Credentials of MEC user.

Abuse Case2: Malicious Program which is running in mobile device will capture the server

Login Credentials from the configuration file in which the server login exists.

Abuse Case3: Malicious Program which is running in mobile device will modify the Email

data at Client level as well as at Server level.

Abuse Case4: Malicious Program which is running in mobile device will

steal/corrupt/modify the contents of important email data which consists in plain text or

multimedia data

From the above Abuse Case we have identified the main Assets, those are:

Data like Email content, User login credentials, User account information,

Configuration file, Email client code.

Email Server: Since MEC to up and running Email Server is one of the most

important asset and the server should not have threat from MEC.

Handheld devices: Malicious program should not corrupt the Device system and

MEC to up and running, handheld device should be working. So Handheld device is

also considered as an asset.

Security Requirements:

The need for prevention of virus, malicious software which if present in the handheld

devices will result in the confidentiality, integrity, privacy violation.

The need for securing the connection between the client and the email server in order

to maintain data confidentiality, integrity, privacy.

The need for preventing spam mails in order not to overload the server and handheld

devices.

The need for preventing phishing in email in order to protect the customer details and

maintaining their trust, privacy.

The need for protecting the mobile email client code for maintaining integrity

constraint and confidentiality constraint, privacy.

The needs for protecting the configuration file from being accessed by anyone except

the mobile email client for maintaining confidentiality, integrity.

=================================================================

=================

Challenge 2:

Use the security requirements and the given design to identify potential vulnerabilities and

threats for this system. For this identify the assets, possible attacks, counter measures etc.

You can choose any method for this purpose.

Solution:

Virus - Responsible for destructive payloads, destroying data and bringing down

entire mail systems. E.g.: Internet Worms, Mass mailer viruses tend to stay longer

even if antivirus products have included protection against them in their products

leading to loss of money, resources & effort to recover from such incidents, loss of

productivity, corrupt or lost data & loss of user confidence.

Phishing (Identify Theft) – It targets the customers of financial institutions and high-

profile online retailers by luring them to spoofed websites and give their credentials.

This leads to personal information revelation to other people thereby violating the

confidentiality of the data.

Spam – It bring down system availability and also can carry viruses, malicious code

and fraudulent solicitations for private information. It overloads network and server

resources.

Adversary who are eavesdropping on the channel between the client and the email

server, capturing the data and modifying the data according to his need and resending

again.

Buffer overflow due to lack of coding for MEC

Solution to Threats:

Use of anti-virus software which will remove virus, malware program and un-trusted

program, anti spam solution like blacklist the list of spam users rather than deleting

the mails every time the mail comes, enabling the email spam filter and anti phishing

solutions like Caller ID by Microsoft, Sender Policy Framework by Meng Wong,

Domain Keys by Yahoo etc.

Use of secure protocol like SSL (Secure Socket Layer).

The wrapping of client code, configuration file with anti-virus software, anti-spam

solution, anti-phishing solution which will act as the firewall for the client code.

Secure coding for MEC will overcome from buffer overflow issues.

=================================================================

=================

Challenge 3:

Some code fragments are provided for security review. Identify the secure code related issues

and suggest modifications to the code using secure code practices.

Solution:

Fragment 1:

void f(char *src1, char* src2)

{

char dest[DEST_SIZE];

// check to make sure first string fits

if (strlen(src1) > sizeof(dest)) return;

strcpy(dest, src1);

// copy as much of the second string as will fit

strncat(dest, src2, sizeof(dest));

...

}

Threats:

1. Threat of changing both src1 and src2 values in this function

2. strncpy() and strncat() functions are a source of bufferoverflow vulnerabilities.

Secure Code:

void f(const char *src1, const char* src2)

{

char dest[DEST_SIZE];

// check to make sure first string fits

if (strlen(src1) > sizeof(dest)) return;

strcpy_s(dest, src1);

// copy as much of the second string as will fit

strncat_s(dest, src2, sizeof(dest));

...

}

Fix:

1. Input arguments made const.

2. strncpy_s and strcat_s functions are secure for buffer vulnerabilities.

Fragment 2:

char buff1[MAX_SIZE], buff2[MAX_SIZE];

out = buff1;

// make sure it‟s a valid URL and will fit

if (! isValid(url)) return;

if (strlen(url) > MAX_SIZE – 1) return;

// copy up to first separator

do {

// skip spaces

if (*url != ‟ ‟) *out++ = *url;

} while (*url++ != ‟/‟);

strcpy(buff2, buff1);

...

Threats:

1. Unknow variable “out” & assuming it as char array, there is no check done with

size.

2. URL length is never verified. There is a chance of pointer going beyond array

length. Accessing values from unassigned memory locations.

Secure Code:


if (strlen(out)==MAX_SIZE) out = buff1;



if (strlen(url) > MAX_SIZE - 1) return;

int len_url = strlen(url), urlIndex=0,outIndex=0;


do {

// skip spaces

if (*(url +urlIndex)!= ‟ ‟) *(out+outIndex) = *(url+urlIndex);

urlIndex++;

outIndex++;

if(*(url+urlIndex)==„/‟)

break;

} while (urlIndex<len_url);

strcpy_s(buff2, buff1);

...

Fix:

1. Length of the variable “out” has been checked before assigning the values.

2. URL length has been verified properly.

Fragment 3:


out = buff1;



if (strlen(url) > MAX_SIZE – 1) return;


do {

// skip spaces

if (*url != ‟ ‟) *out++ = *url;

} while (*url++ != ‟/‟) && (*url != 0);

strcpy(buff2, buff1);

...

Threats:

3. Unknow variable “out” & assuming it as char array, there is no check done with

size.

4. URL length is never verified. There is a chance of pointer going beyond array

length. Accessing values from unassigned memory locations.

Secure Code:


if (strlen(out)==MAX_SIZE) out = buff1;



if (strlen(url) > MAX_SIZE - 1) return;

int len_url = strlen(url), urlIndex=0,outIndex=0;


do {

// skip spaces

if (*(url +urlIndex)!= ‟ ‟) *(out+outIndex) = *(url+urlIndex);

urlIndex++;

outIndex++;

if(*(url+urlIndex)==„/‟ || *(url+urlIndex)==0)

break;

} while (urlIndex<len_url);

strcpy_s(buff2, buff1);

...

Fix:

3. Length of the variable “out” has been checked before assigning the values.

4. URL length has been verified properly.

Fragment 4:

void *ConcatBytes(void *buf1, size_t len1, char *buf2, size_t len2){

void *buf = malloc(len1 + len2);

if (buf == NULL) return; // allocation failed

memcpy(buf, buf1, len1);

memcpy(buf + len1, buf2, len2);

...

}

Threats:

1. Threat of changing both buf1 and buf2 values in this function

2. memcpy function is a source of bufferoverflow vulnerabilities.

Secure Code:

void *ConcatBytes(const void *buf1, size_t len1, const char *buf2, size_t len2)

{

void *buf = malloc(len1 + len2);

if (buf == NULL) return; // allocation failed

memcpy_s(buf, len1, buf1, len1);

memcpy_s(buf + len1, len2 buf2, len2);

...

}

Fix:

1. Input arguments made const.

2. memcpy_s function is secure from buffer vulnerabilities.

Fragment 5:

#define MAX_BUFF (64)

BYTE bBuff[MAX_BUFF];

DWORD cbBuff = 0;

…

// Determine how much data // to read

RegQueryValueEx ( hKey,

NULL,

NULL,

NULL,

&cbBuff );

...

// Read ALL the data!!!

RegQueryValueEx ( hKey,

NULL,

NULL,

bBuff,

&cbBuff );

…

Threats:

1. Function(how much datato read) return value is not verified to check status of request

2. Not verifying if cbBuff is greater than MAX_BUFF

Secure Code:

#define MAX_BUFF (64)

BYTE bBuff[MAX_BUFF];

DWORD cbBuff = 0;

…

// Determine how much data // to read

If(RegQueryValueEx ( hKey, NULL, NULL, NULL,&cbBuff ) > 0)

{

...

If(cbBuff>MAX_BUFF)

bBuff=new BYTE[cbBuff];

// Read ALL the data!!!

RegQueryValueEx ( hKey, NULL, NULL, bBuff, &cbBuff );

}

…

Fix:

1. Return value is been verified for how many data to read. If its greater than 0 then

reading of data function is called otherwise not.

2. cbBuff length is verified with MAX_BUFF, if its miss match then its re-initialized.

Fragment 6:

…

SqlConnection sql = new SqlConnection( @”data source = localhost;” + “user

id = sa;password = password;” );

String sql = “select * from client where name = „” + name + “‟”;

Threats:

1. Both UserId and Password values should not be hard coded in the code.

2. SQL injection attack may possible.

Ex: Password=„abc‟ or „x‟=„x‟;

Secure Code:

…

String id=getUserId();

String pass=getPasswd();

SqlConnection sql = new SqlConnection( @”data source = localhost;” + “userid = ” +id+

“;password=” + pass+ “;” );

String sql = “select * from client where name = „” + name + “‟”;

If(checkSyntax(sql) < 0) return;

…

Fix:

1. Values should be read from the configuration file.

2. Checksyntax(sql) over comes with SQL injection attack.

==================================================================

================

Challenge 4:

Identify atleast 4 design patterns that can be used to enhance the security for this product?

Modify the design to include these design patterns.

Solution:

The four secure design pattern suggested by our team are:-

1.Thin client: process centrally, present locally

In this pattern sensitive data stays centralised in hardened bunkers, with remote devices

allowed views of it via thin-client terminal applications. Because network access is required,

thin client doesn't support offline use. The advantage of thin client is that data never leaves

the server - it is only rendered on the endpoint. For additional security, we can restrict host

copy-and-paste operations, limit data transfers, and require strong or two-factor

authentication using SecurID or other tokens.

The Thin Client application pattern consists of three components:

Presentation component on the client device

Application component (back-end)

Data storage (back-end)

The presentation component is the user interface component on a device. It renders data of

certain formats depending on its capabilities when its connected to the server.

Application logic is delivered by the application component located in the back-end. It also

manipulates data supplied by the data storage component (in the back-end) and delivers the

data to the presentation component on the device. The application component may represent a

new application, a modified existing application, or an unmodified existing application.

Additional services are required to prepare the data stream and to adapt the content to the

capabilities of the presentation component (the devices user interface). Security and

administration services are necessary to ensure that the device users can achieve a single

sign-on to existing applications.

Advantage:Since data is not stored on the mobile client,so viruses/malicious programs can‟t

tamper with data whenever user is offline.

2.Thin device: replicated data, with device-kill for insurance

The thin device pattern constrains access by limiting the type of device used to access the

data. Point-purpose devices like smartphones, for example, can keep only limited amounts of

sensitive information on them. The information they keep is replicated, with master copies

stored in data-centers . Because of their size, storage capacity, and comparatively modest

processing power, applications are limited to e-mail, light web-surfing, and simple web

applications, rather than general data processing.

EMC Symmetrix thin devices are logical devices that can be used in many of the same ways

that Symmetrix devices have traditionally been used. Unlike traditional Symmetrix devices,

thin devices do not need to have physical storage completely allocated at the time the device

is created and presented to a host.

A thin device is not usable until it has been bound to a shared storage pool known as a thin

pool. Multiple thin devices may be bound to any given thin pool. The thin pool is comprised

of devices called data devices that provide the actual physical storage to support the thin

device allocations. When a write is performed to a part of any thin device for which physical

storage has not yet been allocated, the EMC Symmetrix allocates physical storage from the

thin pool for that portion of the thin device only.

The minimum amount of physical storage that can be reserved at a time for the dedicated use

of a thin device is referred as a data device extent. An entire thin device extent is physically

allocated to the thin device at the time the thin storage allocation is made as a result of a host

write operation. The data device extent is allocated from any one of the data devices in the

associated thin pool. Allocations across the data devices are balanced to ensure that an even

distribution of allocations occurs from all available data devices in the thin pool.

The minimum amount of physical storage that must be mapped to a thin device at a time is

called a thin device extent. For EMC Symmetrix, the thin device extent size is the same as the

data device extent size.When a read is performed on a thin device, the data being read is

retrieve from the appropriate data device in the thin pool to which the thin device is

associated. If for some reason a read s performed against an unallocated portion of the thin

device, zeroes are returned to the reading process.

When more physical data storage is required to services existing or future thin devices, for

example, when a thin pool is approaching full storage allocations, data devices can be added

to existing thin pools dynamically without needing a system outage. New thin devices can

also be created and associated with existing thin pools. When data devices are added to a thin

pool they can be in an enabled or disabled state. In order for the data device to be used for

thin extent allocation it needs to be in the enable state. For it to be removed from the thin

pool, it needs to be in a disabled state. A data device can be disabled only if it does not have

any thin extent allocations.

Advantage:Using native management tools or third-party mobile device platforms like

Sybase, smartphone security policies that can typically be imposed include backup and

enforced encryption. Since encryption is ensured threats like data modification, information

disclosure won‟t happen.

3. Protected process: local information processing in a secure "bubble"

Unlike the thin client pattern, which keeps sensitive data off of client devices entirely, the

protected process pattern allows data to be processed locally on non-IT-owned machines.

Sensitive information sits inside a compartmentalised processing environment that is

separated from the user's local operating system environment - essentially a "bubble" - whose

security and backup properties are controlled by security policy like granular security control.

Granular security Control:

Control who sees what

With sharing, you can ensure record-level access control for all custom objects as well as

many standard objects (such as Account, Contact, Opportunity, and Case). Administrators

can set organization-wide default sharing access levels and then grant additional access based

on record ownership, role hierarchy, sharing rules, and manual sharing. Developers can write

code that grants additional access programmatically.

Fine-grain control over sharing rules

To specify the objects and tabs a user can access, you can assign a profile. To specify the

fields a user can access, you can use field-level security. To specify the individual records a

user can view and edit, you can set your organization-wide defaults, define a role hierarchy,

and create sharing rules.

Remote Wipe a Mobile Device:

If your user has Google Sync configured on a supported mobile device or an Android device

with the Google Apps Device Policy app installed, you can use the Google Apps control

panel to remotely wipe the device.

Use this feature when a device is lost or stolen to erase all data on the device and reset the

device. Your user's device must already have Google Sync or Device Policy configured. You

cannot install Google Sync or Device Policy and run Remote Wipe retroactively.

Important: A remote wipe removes all device-based data like mail, calendar, and contacts

from the device, but it may not delete data stored on the device's SD card. A user's Google

Apps data remains available through a web browser or other authorized mobile devices.

To remote wipe a lost or stolen device:

Sign in to your Google Apps control panel.

Click Settings > Mobile.

In the Devices tab, hover your cursor over the user whose device you want to wipe.

Click Remote Wipe in the box that appears.

A second box appears asking you to confirm that you want to remotely wipe the

device. If you are sure your want to wipe the device, click Wipe Device.

Google Apps displays a message that the device has been successfully wiped. On the next

sync, all content will be deleted and the settings reset to the defaults for this device.

Advantage:The protected process pattern has many advantages: local execution, offline

operation, central management, and a high degree of granular security control(who sees

what), including remote wipe.

4.Protected data: documents protect themselves regardless of location

Whereas all of the previous patterns seek to control the operating environments that process

information, the protected data pattern protects the data itself. Technologies like enterprise

rights management enshrine access rules into documents directly. These rules, which rely on

cryptography to enforce, apply no matter where the document rests - a key advantage.

Cryptography:

Cryptography is the practice and study of techniques for secure communication in the

presence of third parties (called adversaries).More generally, it is about constructing and

analysing protocols that overcome the influence of adversaries and which are related to

various aspects in information security such as data confidentiality, data integrity, and

authentication.

Advantage: protected data is the most fine-grained and effective because it focuses on the

information, not its containers. Nobody can misuse even if any user information is leaked,

tampering ,identity theft, information disclosure is taken care of.

Challenge 6:

Now the Kumar and team is facing another dilemma, should they consider a redesign of the

product to ensure all security Suggest Measures of deterrence, identification and recovery

that should be built for this system. These measures may require redesign of the system.

Should the team halt the current release and redesign the system to provide for security OR

should they postpone the process to later releases of the product? What do you suggest and

why?

Suggestion:

SoftCorp should not go for complete redesign, since complete code is already done. Hence

below strategy can be used for security review of the product:-

Threat Modelling

Test Planning

Test Execution

Security Bug Fixing

Applicable Tests:

Authentication Testing

Input Validation Testing

Session Management Testing

Encryption Testing

Application Testing

Benefits of Threat Modelling.These are some benefits of threat modelling:-

Complex design level security bugs can be easily identified if we incorporate the

threat modelling.

More over multi-step security bugs (several small failures combining to form a

disaster) are best found using threat modelling.

it also will also help us to understand our application better, since we would spend

time analysing the makeup of the application in a relatively structured manner.

It yields useful documents which the testing team could use to test against.

Challenge 5:

Take any four (4) use cases related to email functionality and performthreat modeling for the

same. Generate the threat tree as well. For thisfollow the complete process of threat

modeling. Build attack trees foratleast 4 potential attacks. Report various assets, DFDs,

potential threats,vulnerabilities, attack trees, counter measures, risk score etc.

Threat modeling is a repeatable process which involves a methodical analysis of system design or architecture to discover and mitigate threats to an application. There are 6 steps steps in thread modelling process.

1. Identify Security Objectives

2. Create an Application Overview

3. Application Decomposition

4. Identify Threats

5. Categorize and prioritize the threats

6. Mitigation Measures

Use-Case 1: Sending an e-mail

1. Security Objectives:

Confidentiality (No Eavesdropping) - The Internet is a big place with a lot of people on it. It is very easy for someone who has access to the computers or networks through which information is travelling to capture this information and read it.

Privacy (NoInvasion of Privacy) - Recipients may be able to determine the IP address or the email client used for sending the mail. They can use this information to find in which city sender is located or even to find out the address in some cases. This is not an issue with Webmail, POP, or IMAP, but is an issue with the transport of email, securely or insecurely, from any email client over SMTP.

Integrity (No Tampering) - Anyone who has system administrator permission on any of the SMTP Servers that message visits, can not only read the message, but they can even change the message before it continues on to its destination. Recipient has no way to tell if the email message that was sent has been altered.

Non-repudiation (No repudiation) - Because normal email messages can be forged, there is no way to prove that someone sent you a particular message. This means that even if someone DID send you a message, they can successfully deny it. This has implications with regards to using email for contracts, business communications, electronic commerce, etc.

No Spam and Unwanted Email – Any virus or other program should not be able to send spam or unwanted mails from MEC.

http://luxsci.com/extranet/info/email-pop.html

http://luxsci.com/extranet/info/email-imap.html

http://luxsci.com/extranet/info/email-smtp.html

2. Application Overview:

User with a valid email account and who is logged in to the email client can compose and send a mail by specifying the receiver’s email address.

Users - Senders with authenticated account at some email provider like Yahoo, Gmail etc.

Technologies -

Network : Wireless network, Bluetooth

Protocol : SMTP (Simple Mail Transport Protocol) ,ESMTP , POP3, IMAP4

Description -

1. Compose an email

2. Press the send button

3. Application Decomposition:

4. Threats

1. Disclosure of Information: Most of emails are transmitted in the clear (not encrypted) text. By means of some available tools, persons other than the designated recipients can sniff the packets and can read the email contents. Email messages are stored on SMTP servers in plain, unencrypted text. Backups of the data on these servers may be made at any time and administrators can read any of the data on these machines.

2. Modification of messages: Email contents can be modified during transport or storage.

3. Repudiation: Because normal email messages can be forged, there is no way for you to prove that someone sent you a particular message. This means that even if someone DID send you a message, they can successfully deny it.

4. Identity Theft: If someone can obtain the username and password that you use to access your email servers, they can read your email and send false email messages as you.

5. Denial of Service – MEC is not allowed to send an email.

6. Spoofing – Some program can change the message before sending.

Figure:Threat tree for information Disclosure


Once we have categorized the threats it is important to prioritize the threats. To do that one common method is to calculate the risk where Risk = Probability of Occurrence X BusinessImpact

1. Identity Theft, Information Disclosure – High

2. Modification of messages - Medium

3. Repudiation, Denial of Service, Spoofing - Low


Encrypting an EMAIL message

Encrypt the message before sending. Use encryption algorithms like authenticated Diffi-Hellman key exchange. This solves the problem of eavesdropping and Disclosure of Information

Encrypting the TRANSMISSION of an email (SMTP/POP/ESMTP/IMAP4 over SSL/TLS)

While connecting to mail server, email credentials (username and password) are encrypted, protecting them from being intercepted by malicious users as they traverse the internet from email client to mail server.

Identity Theft

No one can steal the sender’s login information because the sender and its mail server use SSL connections.

Disclosure of Information and Modification of messages

No one can eavesdrop on message in between sender’s mail client to its mail server channel because the mail will be encrypted twice (once before sending by the encryption algorithm and then by SSL). At the mail server mail will be decrypted only once by the server (for SSL encryption) but as the mail was already encrypted before sending by the Encryption Algorithm and only receiver can decrypt the mail therefore it will be safe at the mail server as it is in encrypted form. In between sender’s mail server to towards receiver’s mail server channel (this channel may or may not use SSL) mail is still in encrypted form and no disclosure of information or modification of message is possible.

Denial of Attack, Spoofing attacks will be handled by the security system integrated with the MEC.

(OR) Security with Escrow Encryption

Escrow encryption uses a trusted “encryption middleman” to provide the same security

offered by asymmetric key encryption, but with universal compatibility.

The sender ands receiver connects to the middleman‟s web mail portal on a secure SSL

connection.

There will be no information disclosure in communication channel and no identity theft as

both sender and receiver are on secure SSL connection.

There will be no repudiation as the middleman validates the sender.

The middleman encrypts the message and stores it on his server. Therefore no one can

modify the message because it never leaves the middleman‟s server and it will be secure even

in backups.

Use-Case 2: Receiving an e-mail

1. Security Objectives:

Confidentiality (No Eavesdropping) – Any third person having access to my network should not be able to read my mail.

Privacy (NoInvasion of Privacy) – Recipients may be able to determine the IP address or the email client used for sending the mail. They can use this information to find in which city sender is located or even to find out the address in some cases. This is not an issue with Webmail, POP, or IMAP, but is an issue with the transport of email, securely or insecurely, from any email client over SMTP.

Integrity (No Tampering) - Anyone who has system administrator permission on any of the SMTP Servers that message visits, can not only read the message, but they can even change the message before it continues on to its destination. Recipient has no way to tell if the email message that was sent has been altered.

Non-repudiation (No repudiation) Because normal email messages can be forged, there is no way to prove that someone sent you a particular message. This means that even if someone DID send you a message, they can successfully deny it. This has implications with regards to using email for contracts, business communications, electronic commerce, etc.

Phishing Attack

Damage due to viruses, spyware, and spam.

Memory Overflow

2. Application Overview:

http://luxsci.com/extranet/info/email-pop.html

http://luxsci.com/extranet/info/email-imap.html

http://luxsci.com/extranet/info/email-smtp.html

User with a valid email account and who is logged in to the email client can receive email address.

Users - Senders with authenticated account at some email provider like Yahoo, Gmail etc.

Technologies -

Network : Wireless network(WAP, GPRS, Wi-Fi etc), Bluetooth

Protocol : IMAP, POP

Description -

1. Open MEC and check mails


Same as Use-case 1.

4. Threats:

1. Disclosure of Information

2. Modification of messages

3. Repudiation

4. Identity Theft

5. Phishing Attack

6. Damage due to viruses, spyware, and spam

7. Memory Overflow


1. .Identity Theft, Information Disclosure, Memory Overflow - High

2. Modification of messages, Phishing Attack, Damage due to viruses, spyware, and spam - Medium

3. Repudiation - Low


Encrypting the RECEIPT of an email (IMAP4 / POP over SSL/TLS):

While connecting to mail server, email credentials (username and password) are encrypted, protecting them from being intercepted by malicious users as they traverse the internet from mail server to email-client.

Disclosure of Information and Modification of messages:

As the mail is encrypted before sending and only receiver can decrypt the mail no one can eavesdrop on the message between sender to receiver.

Repudiation:

As we are using authenticated Diffie-Hellman key agreement protocol for encryption and SSL channels there is no repudiation threat.

Memory Overflow:

Attachments will be kept at the server and they can be downloaded only after user’s permission and user can set the maximum download limit. Therefore there will be no memory overflow.

Damage due to viruses, spyware, and spam:

E-mail Client integrated security system will take care of all the viruses, spywares and spam mails on the device. It will notify the user about spam mails and user will have an option to either keep or delete them. User will also have an option to integrate security system present on PDA or smartphone with the email-client.

If we are using Escrow Encryption the middleman server will have spam filters, antivirus softwares running on it and they will take care of phishing, damage due to viruses, spyware, trojans, spam etc related threats.

Use-Case 3: Synchronizing between Mobile Email Client and Email Server

1. Security Objectives

Confidentiality (No Eavesdropping) – When the user request a particular account to

be synchronized with the email server, the data transmission that is taking place

between the Mobile Email Client and the Email Server must be encrypted using some

efficient encryption algorithm. Otherwise the adversary (i.e. third party) will be able

to listen to the data that is being sent over the insecure channel thereby leading to

loss of data being known to the outside world.

Integrity (No Modification of Data) – Sometimes the adversary (i.e. third party) will

capture the data that is being sent and modify them thereby leading to loss of the

original data.

Mobile Email Client must be able to avoid spam and phishing emails by using anti-

spam solutions like using anti-spam filter, maintaining a blacklist of spam creators,

etc. and anti-phishing solutions like maintain a sender authentication for every mail

that is sent using Sender Policy Framework , Caller-Id, Domain Keys, etc. Otherwise it

will lead to memory overflow.

2. Application Overview

o The various interactions among the email system are being discussed in this

section.

User – User with authenticated account can request for synchronize

email.

Technology

Network : Wireless Network

Protocol : SMTP (Simple Mail Transfer Protocol)

Description:

After the user has successfully logged in and has established the connection with the server,

he/she selects one account and click on the synchronize button which is in the Options

Menu. Then the mail contents in all the folders along with folder hierarchy is retained from

the server and is displayed to the user.


Same as in Use-case 1.

4. Threats

o Disclosure of Information - Most of emails are transmitted in the clear (not

encrypted) text. By means of some available tools, persons other than the

designated recipients can sniff the packets and can read the email contents.

Email messages are stored on SMTP servers in plain, unencrypted text.

Backups of the data on these servers may be made at any time and

administrators can read any of the data on these machines.

o Modification Of Messages - Email contents that are present in the folder can

be easily modified by the adversary if the adversary is able to capture the

email and if the email is travelling in insecure channel.

o Identity Theft – The mail, sent in insecure channel, will be captured by the

adversary (i.e. third party) who can insert a new email to get the personal

information of the user.

Figure: Threat Tree for Modification of Message




2. Modification of messages– Medium


o Encrypting an EMAIL message - Encrypt the message before sending. Use

encryption algorithms like authenticated Diffi-Hellman key exchange or RSA

Algorithm. This solves the problem of eavesdropping and Disclosure of

Information.

o Security with Escrow Encryption – Escrow encryption uses a trusted

encryption middle-person who will provide the security. Here the sender and

the receiver connect to the middleman‟s mail portal using secure SSL

connection. There is no possibility of repudiation as the middle-person

validates the sender.The middleman encrypts the message and stores it on his

server. Therefore no one can modify the message because it never leaves the

middleman‟s server and it will be secure even in backups.

Use-Case 4: Creation/Deletion/Renaming of folder and its permissions.

1. Security Objectives

o Confidentiality of data – The virus, if present in the handheld devices, can try

to access the emails that are present in the various folders. If the permissions

of the folders are not properly given when created, the following problems

occur.

The virus, if present in the handheld devices, will read the contents of

the folders(mails) thereby leading to confidentiality violation i.e.

reading our mails by unauthorized programs and persons and privacy

violation i.e. reading personal information, credit card details etc. by

unauthorized persons and programs.

o Integrity of data – The virus, if present in handheld devices, can modify the

contents of the email thereby leading to integrity violation as the permission

of the folders are not properly defined when the folder is created and the

permission is not modified. The virus can altogether delete the entire folder

thereby leading to loss of data.

2. Application Overview

o The various interactions among the email system are being discussed in this

section.

User – User with authenticated account can request for synchronize

email.

Description:

The user has the option of creating a folder modifying the folder name and deleting the

folder created by him. The most important thing is the permission given to the folder. There

are three types of permission – Read(r), Write (w), Execute(x) to three different types of

user owner, group(group of accounts for that user) and others. He will grant permission to

those users.

3. Application Decomposition

Same as Use-case 1.

4. Threats

o Disclosure of Information – As the permission of the folder is not given

properly at the time of creation by the user, the virus, if present in the

handheld devices, will open the folder, if the permission is granted or modify

the permission such that the folder is accessible by the virus program, and

read the contents of the email thereby disclosing mail information to the

attacker.

o Modification Of Messages - Email contents that are present in the folder can

be easily modified by the virus present in the handheld devices thereby

modifying the contents according to its needs.

o Identity Theft – The virus can also get the personal information of the user

like account details, credit card information etc. as those information will also

be stored in some folder in the hand-held devices thereby stealing personal

information.

Figure: Threat tree for Identity Theft




2. Modification of messages– Medium


o Giving proper permission to the folders created by the user – This makes sure

that even if the virus is present in the handheld devices, it can‟t access the

folder as the permission is denied. Also since only the administrator can

access the root folder, so the virus can‟t attack through the root folder also to

change the permission of the folder. This ensures confidentiality, Integrity and

privacy.

Diagrams

A sequence Diagram for the Continuous, Two Way Synchronization Feature

Main Classes Involved in the Proposed Email Client System

High Level Architectural Diagram For Pocket Email Client

Final report

Technology

Transcript of Final report