1. 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

2. 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.

3.  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));
...

4. }
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

5. 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:
char buff1[MAX_SIZE], buff2[MAX_SIZE];
if (strlen(out)==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;
int len_url = strlen(url), urlIndex=0,outIndex=0;
// copy up to first separator
do {
// skip spaces
if (*(url +urlIndex)!= ‟ ‟) *(out+outIndex) = *(url+urlIndex);
urlIndex++;
outIndex++;
if(*(url+urlIndex)==„/‟)

6. 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:
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++ != ‟/‟) && (*url != 0);
strcpy(buff2, buff1);
...
Threats:

7. 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:
char buff1[MAX_SIZE], buff2[MAX_SIZE];
if (strlen(out)==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;
int len_url = strlen(url), urlIndex=0,outIndex=0;
// copy up to first separator
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){

8. 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:

9. #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;
…

10. // 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:

11. …
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.

12. 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

13. 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

14. 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.

15. 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:

16. 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.

17. 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

18. 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
5. Categorize and prioritize the threats

19. 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
6. Mitigation Measures
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.

20. 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:

21. 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
3. Application Decomposition:
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
5. Categorize and prioritize the threats
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
6. Mitigation Measures
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.

22. 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

23. 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.
3. Application Decomposition:
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.

24. Figure: Threat Tree for Modification of Message
5. Categorize and prioritize the threats
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
6. Mitigation Measures
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.

25. 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

26. 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
5. Categorize and prioritize the threats
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

27. 2. Modification of messages– Medium
6. Mitigation Measures
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

28. Main Classes Involved in the Proposed Email Client System

29. High Level Architectural Diagram For Pocket Email Client