MOBILE SECURITYStudent Guide
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 4
This is the first of a series of modules in the Security Track. This module has two
objectives:
First to convey an understanding of why mobile (wireless) security is so
fundamentally different from the wired systems that have been the mainstay of
IT systems in the past.
The second objective is to list and describe the four types of mobile phone
platform with an eye towards how the manufacturers of these products deal
with the security challenges. That part of the topic is covered in later modules.
CONTENT
THEMES
• Architecture, Security
Module 1, mGov Training Introduction
mGovernment
Module 1 : UnderstandingSecurity
5
Understanding Security
Module 1, mGov Training IntroductionModule 1: Understanding Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 6
This module introduces the objectives:
1. Understand the fundamental wireless security difference.
2. List the four handheld platforms and understand their origins.
mGovernment 7
Module 1: Understanding Security
• Understand the fundamental wireless security difference.
• List the four handheld platforms and understand their origins.
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 8
1. Introduce Sun Tzu.
2. Introduce the idea that to understand defense, you must also understand
offense.
CONTENT
We begin the journey of starting to think like security people by going back to
ancient times…
Circa 500BC when Sun Tzu said in his book The Art of War: “Know your enemies
and know yourself, and you need not fear the result of 100 battles.”
This is as true today as it was in 500BC. So let us start thinking like the adversary.
Mobile government services depend on wireless connection interfaces.
That is the whole point of mobile – to get untethered from the wire. Why is it
that hackers (the adversaries) find wireless (mobile) systems more vulnerable to
attack?
mGovernment 9
How To Think About Security
Module 1: Understanding Security
Know your enemies and know yourself,
and you need not fear the
result of 100 battles.
Paraphrased Translation, Sun Tzu – The Art of War,
circa 500BC
• To know our enemy, we must
become our enemy.
• To know how to defend ourselves,
we must know how to attack
ourselves.
Sources
https://en.wikipedia.org/wiki/Sun_Tzuhttp://classics.mit.edu/Tzu/artwar.html
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 10
Why is wireless security fundamentally different? Let’s do a little experiment and
see if we can answer that question.
Consider the visual of 4 volunteers to help convey this concept.
Two of the volunteers each take one end of a computer network cable called a
Category 5 or Cat 5 cable. They pull it taught. The two volunteers in our visual
description represent critical servers communicating with each other over that
dedicated connection in the datacenter.
The third volunteer is the datacenter security manager whose job is to protect
the data traveling over this wire between the two servers. To make the visual
more interesting, let’s have the security manager reading a newspaper to pass
the time – waiting for something to happen.
The fourth volunteer represents an attacker. The stage is now set. In order for
the attacker to gain access to the data on this wire, he or she has to physically
penetrate the datacenter, and physically access (touch) the network cable inside
of that data center.
CONTENT
1. Understand that the fundamental difference between wired and wireless
network security stems from the physical layer
mGovernment 11
Module 1: Understanding Security
• Why is wireless security different?
• Need four volunteers….
• Hopefully, this:
• Helped you focus your thoughts on
the wireless difference
• Enables you to explain why wireless is
different to your peers and bosses
Demo
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 12
CONTENT
The datacenter security manager is diligent. He is keeping watch, ready to
defend the security of the data center. As the attacker reaches for the wire, the
datacenter manager rolls up that newspaper that he was reading and repels the
attack.
Volunteers, thank you.
This may seem like a silly demonstration, but consider: If an attacker wants
access to the data on this wire, he has to physically touch the wire. This is the
point – a rather obvious point.
But how does it work with Wireless? Is it the same? Not at all. If you can hear my
voice, you are in radio range, and you have access to the media. With wired,
the security is in the physical layer as in the wire. With wireless there is not the
same physical layer to provide protection and isolation. The radio frequency is
readily accessible from the parking lot of the building and with the right
technology possibly even much farther away. In wireless there is no need
to gain entry into the building and face the security manager. That is how
fundamentally different wireless is and why we need to recognize this in
our planning for securing the mobile (wireless) communications. Think
encryption.
As a way to wrap up this demonstration remember back to your time as a child.
Many of you may have played with tin can telephones. In order to hear the audio
mGovernment 13
Module 1: Understanding Security
CONTENT
in the can it requires that you hold the can in your hand, next to your ear. In
other words, you have to touch the media, the string and the cans. With a
normal voice conversation that’s not necessary, and neither is it with wireless.
Hopefully, this helps bring to focus the fundamental difference between the
security needed for wired and the security that is needed for wireless. It may
also provide a tool or two to help you explain this to others.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 14
CONTENT
Consider the four major handheld smart phone platforms in the UAE market.
These are the four that the Telecommunications Regulatory Authority, TRA
tracks closely. There are others which may gain market share in the future. But
for now these are the major players.
Each of these platforms has its own strengths and weaknesses, but they all share
one feature; they will all be communicating with Back End computing resources
in the data center. So we really have to worry about not four, but five potential
security problem areas, each of the platforms and the computer system
resources that we find in the Back End.
1. Introduce the 4 major handheld platforms.
2. Emphasize that the problems is not limited to the handheld.
mGovernment 15
Module 1: Understanding Security
• Common Mobile Platforms
• BlackBerry
• Windows Phone
• iOS
• Android
• 1 App = 5 Problems
• 4 Platforms = 4 Problems
• +1 Backend = 5 Problems
mGov Security Problems
Glossary
TRA
Back End
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 16
CONTENT
Let’s look into a little more detail, beginning with the Blackberry.
The Blackberry Operating system came out in 1999, and underwent major
revisions in 2013. We refer to it as a proprietary operating system since it is not
open, but it is based on a Unix operating system variant called QNX. QNX is quite
mature and robust, and was open at one point before blackberry bought QNX
and withdrew the public code.
Today blackberry runs native code specifically built for its QNX version of
its own devices, as well as a subset of Android applications, all on handsets
manufactured by Blackberry.
Blackberry is the only platform that was originally designed for use
in business and government. It is well recognized in the industry as a
platform where security was and remains a primary design consideration.
1. Introduce the Blackberry.
2. Understand that when we discuss Blackberry we must consider the
Blackberry Enterprise Server.
3. Understand that Blackberry is the only one of the four platforms with
business and government origins, not consumer.
mGovernment 17
Developer Site: developer.blackberry.com
Module 1: Understanding Security
• Proprietary OS
• BlackBerry OS
• Released in 1999
• Java Virtual Machine (JVM) based
• BlackBerry 10 OS
• Released January 30, 2013
• Based on QNX Kernel
• Android runtime layer
• “Security First”
Engineered around Security
BlackBerry Overview
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 18
CONTENT
1. Introduce Windows Phone.
The modern version of the windows phone was introduced in 2010.
It actually shares commonality with the Windows 8 operating system, including
being based on the NT operating system kernel.
The Windows phone operating system or OS is licensed by Microsoft to handset
manufacturers, so it runs on several handset devices from different vendors.
These are consumer-oriented devices. This means that unlike the Blackberry
security was not a primary design consideration of the devices or the OS, and
they have a relatively small share of the UAE smart phone market.
mGovernment 19
Developer Site: www.windowsphone.com
Module 1: Understanding Security
Windows Phone Overview
• Proprietary OS
• Windows Mobile OS
• Released in 2000
• Support ended January 2013
• Windows Phone OS
• Released in 2010
• Not backwards-compatible
• Based on Windows NT kernel
• “Security Second”
Usability most important
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 20
CONTENT
1. Introduce iOS and the iPhone.
Apple introduced the iPhone in June of 2007 and it revolutionized the smart
phone market, displacing Blackberry, Nokia, Palm and others who were early
smart phone market leaders.
iOS has Unix roots, is currently on version 9 and runs on iPhone 5 and 6 handsets,
as well as iPads. All are manufactured and sold by Apple.
Like the Windows Phone, these are consumer-oriented devices, meaning
security was not a primary design consideration, even though there is a robust
set of security controls and features in the hardware and OS.
mGovernment 21
Module 1: Understanding Security
iOS Overview
• Proprietary OS
• Based on Unix (BSD) Kernel
• First released June 2007
• iOS 6
• No longer developed
• Last update was February 2014
• iOS 9
• Current iOS version
• iPhone 5; 6 models
• All current iPad models
• “Security Second”
• Usability most important
Developer Site:developer.apple.com/devcenter/ios/
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 22
CONTENT
1. Introduce Android.
Google developed the Android operation system and released it in 2008. It, like
iOS has roots in Unix, in this case being based on the Linux kernel.
Unlike the other three major platforms, the majority of the platform and its
default utilities are open source, which means Google publishes and allows you
to read and modify the source code.
The current version (as of the second Quarter 2014) of Android released by
Google is 4,4, codenamed KitKat, although not all hardware manufactures are
selling devices with the latest version, or providing updates to it. Android 5.X has
been released, but not universally adopted.
Android is also a consumer device, but with a quite robust security model.
As we explore these platforms in later modules of instruction, you will find that
we spend more time discussing Android than the other platforms. That is simply
because it is an open platform, and we know more about it.
mGovernment 23
Module 1: Understanding Security
• Open Source OS
• Based on Linux Kernel
• Released October 2008
• Android 4.1 – 4.3 – Jelly Bean
• Released July 2012 (v4.1)
• Android 4.4 – KitKat
• Released October 2013
• Introduced new run-time environment.
• Android 5.X available.
• “Security Second”
• Usability is most important, but…
• Built on a very secure, common kernel
Android Overview
Developer Site: www.android.com
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 24
CONTENT
It is important to emphasize the origins of the four major platforms under
consideration.
Blackberry is the only one of the four with roots in business and government, and
its security features reflect that.
However, understand that unless your agency is furnishing devices to your
customers or employees, the choice of platform is out of your control.
This means you need to understand your user base, and to be prepared to
support all of them.
1. Discuss Platform Origins.
LEARNING OBJECTIVES
mGovernment 25
Module 1: Understanding Security
“You don’t know who you are unless you know where you came from.”
• Designed for Consumers:
• iOS (iPhone, iPod, iPad)
• Android
• Windows Phone
• Designed for Business and Government:
• BlackBerry
Platform Origins
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 26
Review the Objectives (re-read the slide).
CONTENT
1. Understand the fundamental wireless security difference.
2. List the four handheld platforms and understand their origins.
mGovernment 27
• Objectives
• Understand the fundamental wireless security difference
• List the four handheld platforms and understand their origins
Review of Objectives
Module 1: Understanding Security
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 28
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 29
Module 1: Understanding Security
Quiz – Question 1
Quiz – Question 2
1. Wireless network security is different from wired network
security because of the fundamental differences at the Physical
Layer?
Select one:
a. True
b. False
2. Blackberry is the only one of the four platforms with business and
government, not consumer origins?
Select one:
a. True
b. False
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 32
In this module we review the words from two well-known figures in the security
industry: Dan Geer and Jimmy Kuo. Dan and Jimmy say similar things about the
inherent problem facing us in the security community and the public at large
who are impacted by this inherent problem.
CONTENT
THEMES
Architecture, Security, Business Processes & Collaboration.
• Accessed through the web browser
• Deployed over Internet
• Can develop/design one application for all platforms
• A cross-platform mobile application
• Provides uniformity across all platforms
• Near-instant updates
• Updates to the application are actually updates to the website,
happening on the back-end
Introduction
SDLC: Service Delivery Lifecycle
Glossary
mGovernment 33
Module 2: Architectural Overview Understanding the Problem
Architectural Overview
Understanding the Problem
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 34
Introduce the Objectives, (read the slide).
CONTENT
This module has these objectives:
1. Understand Dan Geer’s “Structural Problem”.
2. Understand Jimmy Quo’s “Cops and Robbers” analogy.
mGovernment 35
Objectives
Module 2: Architectural Overview Understanding the Problem
• Understand Dan Geer’s “Structural Problem”
• Understand Jimmy Quo’s “Cops and Robbers” analogy
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 36
CONTENT
1. Begin to understand Dan’s point.
In his foreword to Carlos Solari’s Security in a Web 2.0+ World, Dan Geer said: “We
are many. They are few. We are losing. They are winning. The reason is structural.”
By “We” he refers to the Information Security community, by “They” he means
the hackers or attackers, in other words, the bad guys.
We’ll expose the structural reason that Dan is talking about in the next several
slides. At the end, we review another point of view on this issue that addresses
the perceptions surrounding this problem.
mGovernment 37
Module 2: Architectural Overview Understanding the Problem
Sources
“We are many. They are few.We are losing. They
are winning.The reason is structural.”
Dan Geer in the Foreword to Security in a Web 2.0+ World by Carlos Solari and Colleagues
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470745754.html
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 38
CONTENT
In the next series of slides we take an admittedly simplified view of the IT systems
development. As the web outgrew its humble beginnings of static web pages, we
moved to dynamic content.
At first this was pretty simple. A generation of software programming languages
were re-purposed or came to be to make it easier to achieve this very need –
how to move from the humble static web pages to the ways that we now take for
granted when we interact with a web site.
One of the first languages re-purposed was PERL. PERL programs allowed
the web server to talk to a backend database using a construct called CGI, or
Common Gateway Interface. We had moved from static informational pages on a
web server to the ability to query a database. Progress.
1. Understand the origins of web applications, and in the coming slides, their
evolution.
mGovernment 39
Module 2: Architectural Overview Understanding the Problem
Brief History of Web Software
GLOSSARY
PERL: Practical Extraction and Reporting Language.
CGI: Common Gateway Interface.
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 40
Along come the security guys, alarmed at the idea that someone on the Internet
could have unfettered access to the internals of a corporate database.
They arrived after the fact as usual, with a firewall and some secure socket layer
or SSL encryption to protect the connection.
You may remember that SSL originated from one of the first commercial
browsers called Netscape.
This is part of the structural problem. The security features, in this case, SSL and
a firewall, were added after the fact, not built into the design and architecture
from the beginning. This is the beginning of the trend we see continue even to
this day.
CONTENT
mGovernment 41
Module 2: Architectural Overview Understanding the Problem
Brief History of Web Software and the security approach
Glossary
Firewall: A policy enforcement device that controls traffic between two
networks.
SSL: Secure Sockets Layer.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 42
CONTENT
1. Expose the format we will use for the next several slides.
As an aid to see the trend we put this instance in time into a table:
The format of the table is: the Date, the enabling web technology, and the
security countermeasure to the risk created by that technology.
The date was circa 1995, the technology was CGI/PERL, and the countermeasures
were a network firewall to enforce policy and SSL to encrypt the connection.
mGovernment 43
Module 2: Architectural Overview Understanding the Problem
First Revision
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 44
CONTENT
1. Begin to see the evolution and increasing complexity in the architecture.
In this next slide we take another snapshot in time – an evolution in web services
capability. Note the innovation inside the web server. Now we have Java Server
Pages and Active Server pages for more rich dynamic content, better session
data, etc.
• What was the corresponding security countermeasure?
Proceed to the next slide and what do we see?
mGovernment 45
Module 2: Architectural Overview Understanding the Problem
Glossary
Evolving Web Software
JSP: Java Server Pages, dynamically generated web pages.
ASP: Active Server Pages (Microsoft scripting for the server side).
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 46
CONTENT
The answer is not much. Firewalls improved, SSL improved, the security
industry started to take notice and began to develop other after-the-fact
security products to aid in countering the increased risk. This and the following
slides emphasize that as “the web” evolved toward what we now know, the
security mechanisms largely did not.
We still depend on SSL and firewalls of one type or another for the bulk of
our protection. The security trend has been to stay the same even as the risk
continued to rise and hackers started to show their skills in ever-increasing and
alarming ways. Breaking in to the network and gaining access to the web sites
was now old.
Breaking into the web application and gaining access to the database of account
information, credit card information was now the purpose.There was money to
be made – criminal money.
mGovernment 47
Module 2: Architectural Overview Understanding the Problem
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL
Second Revision Innovation?
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 48
Continuing on we are now in the multi-tiered back end.
• Has the security mechanism evolved?
CONTENT
mGovernment 49
EJB: Enterprise Java Beans: managed server-side component for modular
construction of enterprise applications.
DCOM: Distributed Component Object Model: MS technology for software
distributed across the network.
Glossary
Evolving Web Software (2)
Module 2: Architectural Overview Understanding the Problem
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 50
CONTENT
The answer to the question from the previous slide is “no”.
Note that the software and architecture is becoming more complex, but
the countermeasures remain largely the same. Yes, there are a host of other
security technologies that entered the marketplace – all of them following
the trend of trying to patch vulnerable systems.
The web services were in such high demand that there was no time given
to the idea that maybe this was not such a good trend. Maybe it was time to
go back and start re-engineering all of this new innovation to make sure that
it was secure. It was 1998 – in the midst of a global tech bubble.
mGovernment 51
Module 2: Architectural Overview Understanding the Problem
Third Revision Innovation?
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 52
In this third generation of the evolving web software we see technologies and
protocols designed to make it faster and easier to get to that rich data in the
back-end. It just keeps evolving…What about the security?
Well yes, there was something new that was added to mitigate against the
growing risk and the hackers who were having their way.
But it was not a net new addition – it was just another firewall added to create
the DMZ and other compartmentalization inside the back end.
SOAP: Simple Object Access Protocol…a protocol for exchanging structured
information in the implementation of web services in computer networks.
XML: Extensible Markup Language.
RDBMS: Relational Database Management System.
ERP: Enterprise Resource Planning.
CONTENT
Glossary
mGovernment 53
Module 2: Architectural Overview Understanding the Problem
A Spectrum of mGovernment Service Delivery Formats
The mGovernment Mission
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 54
So, yes, multiple firewalls came in at some point.
Some of them were specialized technology, specifically Web Application
Firewalls. Still, the story is the same one, it is protection technology added
after the fact and not dealing with the root of the problem – still adding more
band-aids.
CONTENT
mGovernment 55
Web Application Firewall: An application-layer firewall specifically designed
to protect web applications.
Glossary
Fourth Revision Innovation?
Module 2: Architectural Overview Understanding the Problem
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 56
CONTENT
At this point in the history, we can see that the architecture has become
rather sophisticated and very complex. It is a relatively common architecture
these days.
Note the link out to a Partner Application Server. The inevitable began to
happen. In order to streamline the supply chain, IT shops began to connect
directly to partner networks to gain access to their applications – sharing
information directly. The security people and the network people don’t even
have control any longer.
It is a shared control at best or better said, a combined risk with partners
who may common needs but may have entirely different regard for what
constitutes adequate security and even different business agendas.
1. Understand that the complexity is becoming difficult to understand.
Glossary
mGovernment 57
CRM: Customer Relationship Management.
Evolving Software (4)
Module 2: Architectural Overview Understanding the Problem
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 58
CONTENT
The software and architecture continue to evolve. The story has not changed.
Continue through the next few slides and let us bring this to a conclusion.
mGovernment 59
Glossary
SOAP: Simple Object Access Protocol.
REST: Representational State Transfer.
Fifth Revision Innovation?
Module 2: Architectural Overview Understanding the Problem
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 60
In this slide we see the evolution, to Web 2.0 when the web matured beyond
static web pages to interactive information.
CONTENT
mGovernment 61
Glossary
Web 2.0: Web 2.0 suggests a new version of the World Wide Web,
it does not refer to an update to any technical specification, but
rather to cumulative changes in the way Web pages are made and used.
Sixth Revision Innovation?
Module 2: Architectural Overview Understanding the Problem
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL2003 Web 2.0 Network firewalls & SSL
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 62
And evolve it did. Now with the introduction of “Cloud”, you may not be
sure where your data and computing are, which country, continent, etc.
The security industry continued to offer new innovations in the same
ineffective way by layering on security technologies. The root of the problem
started to become clear now. It is vulnerable software code. It is the lack of
foundations of trust. When an operating system is compromised should that
system continue to be trusted? It is if you are not aware of the compromise.
What has been the way to deal with this expanded risk? The same tired
answer: Firewalls and SSL with a host of other similar security technologies. Dan
and Jimmy are right. This is not a revelation. It is old news.
But we have not advanced the security model.
CONTENT
mGovernment 63
Seventh Revision Innovation?
Module 2: Architectural Overview Understanding the Problem
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL2003 Web 2.0 Network firewalls & SSL2007 Cloud Network firewalls & SSL
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 64
And we finally arrive at mobile. Notice the trail of evolution in the Software
column, and the relatively static nature in the Security column.
With minor exceptions, there has been almost no evolution with firewalls or SSL
technology in this time. The reason is structural.
CONTENT
mGovernment 65
We’re now at Mobile Innovation?
Module 2: Architectural Overview Understanding the Problem
Year Software Security
1995 CGI/PERL Network firewall & SSL1997 JSP, ASP Network firewall & SSL1998 EJB, DCOM Network firewall & SSL1999 SOAP, XML Network firewalls & SSL2001 SOAP, REST Network firewalls & SSL2003 Web 2.0 Network firewalls & SSL2007 Cloud Network firewalls & SSL2009 Mobile Improvement needed
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 66
CONTENT
Building on the previous several slides, note the evolution of the technologies on
the back end and of the overall complexity of the environment, and the relative
lack of parallel evolution in the security controls.
We are STILL depending upon after-the-fact security controls rather than secure
design, architecture and coding.
The product developers / vendors continue to supply us, the end users, with
what are essentially defective products, and placing the responsibility to secure
them and the resulting infrastructure on us.
This is the structural problem to which Dan Geer refers.
Another problem is related to perceptions. It is possible “to win”, but refer to the
next slide.
1. Understand that the nature of the problem is largely structural.
mGovernment 67
The Reason is Structural
Module 2: Architectural Overview Understanding the Problem
We are trying to fight this
problem…
…with this older, simpler way of
thinking.
We are not winning now – the reason is structural.
We need a new way
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 68
There is a good lesson here, one that you may read on your own.
Jimmy came up with this around 1 June 2014, and it relates directly to the
perceptions in and of the security community.
The security professionals can succeed or win 1000 times, and their one loss or
failure will end up on the front page of the paper.
The bad guys fail correspondingly as often as we succeed, but you never hear
of that. One win for them results in a failure for us, and we wind up in the paper
again.
This is not fair, but it is real, and the way the world works.
CONTENT
1. Understand the perception component to the structural problem.
mGovernment 69
We’re living in the same world and media circumstances as the cops against
the robbers. The cops have to prevent every crime, but they can’t. The
robbers only have to succeed once, and they’ll make the news, even if it’s
against the most hapless of all potential victims. In fact, the more hapless,
the better the media plays it up. The hapless, after all, are the people who
need the most protection, which the cops were not able to provide.
Occasionally, the cops catch a stupid criminal. And once in a while, the
criminals band together to form gangs. And when that gang creates a big
enough splash, or they piss off the wrong people, the cops take them down.
You know some of the criminals collaborate and trade secrets.
But ultimately, each is in it for his own personal and disjoint benefit. You
know the cops definitely cooperate to do a better job. Their salaries are
hardly a fraction of what the criminals take in. But they do it for their ethics
to be on the right side of Good. Security researchers are of that vein.
It’s not whether the good guys are better or the bad guys are better. It’s
who is able to sleep better at night knowing his ethics align with the great
society we’re all in.
Jimmy Kuo
Senior Architect, Symantec
Jimmy Kuo’s POV:
Module 2: Architectural Overview Understanding the Problem
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 70
Review the Objectives (re-read the slide).
CONTENT
1. Understand Dan Geer’s “Structural Problem”.
2. Understand Jimmy Quo’s “Cops and Robbers” analogy.
mGovernment 71
• Understand Dan Geer’s “Structural Problem”.
• Understand Jimmy Quo’s “Cops and Robbers” analogy.
Review of Objectives
Module 2: Architectural Overview Understanding the Problem
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 72
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 73
Module 2: Architectural Overview Understanding the Problem
Quiz – Question 1
• To complete this module you will need to correctly
answer the End-of-Module Questions. Proceed by answering the first
question.
Dan Geer wrote: “We are many. They are few.
We are losing. They are winning. The reason is structural.” He was talking
about (pick all that apply):
Select one/ or more:
a. The problem of the supply chain where current practice is that
security is expected to be something done by the end-users of
technology devices.
b. That security needs to become part of the systems development
lifecycle (SDLC) in order to change the structural reasons why we are
losing.
c. That there is no way to win against a hacker.
d. That the end is foretold and we might as well give up.
LEARNING OBJECTIVES
INSTRUCTOR GUIDANCE
1. Define HTML 5 Web Applications.
2. Understand pros and cons of HTML 5.
• Instructors will use the slide text to guide them.
• Introduce HTML5 web applications.
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 74
End of Module
mGovernment 75
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 76
CONTENT
Now we will begin discussion of how the architecture will evolve from a security
perspective in the eGov to mGov transition.
Glossary
SYNOPSIS
THEMES
This module covers the introduction to the mGovernment Roadmap and a
discussion of the first track.
Architecture, Security
eGov: Electronic Government, Web-based government services.
mGov: Mobile Government, Government services on handheld, mobile
devices.
Module 1, mGov Training Introduction
mGovernment 7 7
Module 3: A New Architecture
A New
Architecture
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 78
Introduce the Objectives, (read the slide).
CONTENT
1. This module has these objectives:
• Understand the changes to the architecture required by mGov.
• Expose the class to Attack Surfaces, discussed in detail later.
• Expose the class to the high-level differences with mobile applications.
mGovernment 79
Module 3: A New Architecture
Objectives
• Understand the changes to the architecture required by mGov.
• Expose the class to Attack Surfaces, discussed in detail later.
• Expose the class to the high-level differences with mobile applications.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 80
1. Understand a simple n-tier web application architecture.
2. Grasp Basic Terminology, see glossary.
This is a typical, simplified logical diagram of a web-based service as we have in
the eGovernment model. Note the designation of “n-Tier. This means that there
is more than one tier – the n means multiple.
In this diagram there are three that are depicted, within the eGov data center:
the multi-layer back end and the front end.. Again, this is a highly simplified view
of a web-based architecture used here to convey an important security notion.
The “Front End” for eGov is at the boundary of the datacenter, and is typically a
web server. The applications execute (largely) from the front end back to where
data is actually stored, called the “Back End”, all within a datacenter somewhere.
The web browser on the end-user’s computer interprets and displays content
from the front end. In this example, the security between the browser and the
web server is handled by the browser developer and the server developer, and
their security teams. The use of an encrypted channel using secure socket layer
(SSL) is an example of this type of security.
CONTENT
mGovernment 81
Glossary
Front End: The portion of the application that generates the user interface.
Back End: The remainder of the application except for the User Interface.
n-Tier: Multiple Tiered, where the number of tiers is unknown or
unimportant
SAP, Siebel: Example enterprise database solutions.
The n-Tier Architecture (Simplified)
Module 3: A New Architecture
An n-Tier Architecture
Web-based services (eGov)
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 82
CONTENT
The Attack Surface, or the areas where a Hacker can Attack<CLICK>are
intuitively the physical boundaries of the datacenter, and the public-facing
network interface of the front end in that same data center.
In the eGov services model the browser is a window into the information and the
business logic that is contained in the data center. This is the principal target of
a hacker.
Now proceed to the next slide and consider what happens to the Attack Surface
when the architecture changes to include mGov services.
Module 1, mGov Training Introduction
mGovernment 8 3
Module 3: A New Architecture
The n-Tier Architecture (Simplified)
An n-Tier Architecture
Web-based services (eGov)
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 84
1. Understand the origins of web applications, and in the coming slides, their
evolution.
2. Expose the class to the “Attack Surface”.
CONTENT
With mGov, the “Front End” has moved to some degree out of the datacenter
and into the handset.
<CLICK>
This extends and changes the “Attack Surface” of the overall application, which
now extends from the storage in the back end all the way through the multiple
tiers (the n-tier), over the Internet, across the carrier’s network and into the
handheld where the front end now resides.
We will talk in more detail about “Attack Surfaces” in a later module, but we can
introduce the term and use it here.
Security controls in the eGov world that were implemented by the web
server and browser developers now fall to you, the mobile application developer to
implement in your App software code, and in your back end APIs. The Attack
Surface is now expanded. There is more to defend.
mGovernment 85
Module 3: A New Architecture
Migration to the Mobile n-Tier Architecture (Simplified)
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 86
GLOSSARY
App: Mobile Application, specifically in this use, the portion of code actually
running on the mobile platform.
API: Application Programming Interface.
Module 1, mGov Training Introduction
mGovernment 8 7
Module 3: A New Architecture
Migration to the Mobile n-Tier Architecture (Simplified)
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 88
Let us now consider an interesting dilemma in this conversation about eGov and
mGov and the terms front end and back end. In the data center point of view,
the terms front and back end have traditionally referred to the servers such as
web application servers as being the “front end” and the intermediate processing
and storage as being the “back end.” Application Developers, however, have a
different perspective for these terms. In their point of view, the “front end” is
the smart device (smartphone or tablet) where the application is running.
The entire data center in their view of the IT infrastructure is the “back end.”
This difference of perspective has the potential to drive inconsistent design
considerations and can create some confusion. From a security point of view
both these perspectives are partly right. The “front-end” is not one or the
other but in fact both. It is important that these differences be resolved in the
migration from the more traditional eGovernment to the new mGovernment
services architecture.
CONTENT
1. Understand that the terms Front End and Back End take on different meaning
depending on perspective and the application architecture.
Module 3: A New Architecture
mGovernment 89
Front End, Back End: The meanings for this can change depending on
architecture or perspective
Glossary
Front End or Back End?
Data Center
Application Developers
Front EndBack End
IT Systems & Network Staff
Front EndBack End
Data Storage Data Servers Mobile Devices
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 90
In this slide it now becomes clear why this is true. Native applications, the apps
loaded on the smart phones that are now the expanded Attack Surface have
additional security concerns. Native apps address the functional shortcomings
of normal web applications that use the mobile platform browser. They take ad-
vantage of the mobile platform itself, its ability to compute, and specifically the
sensors and hardware components of the phone or tablet.
But they also introduce new problems for the developer from a security point of
view. Mainly, the issues that have been traditionally handled by the commercial
browser developers and their security team.are now the concerns of the app de-
veloper and the owner of the apps – each one of them.
Understanding this is challenging.
OWASP: the Open Web Application Security Project gives a starting point on how
to organize this challenge and think through the appropriate mitigations.
1. Introduce OWASP as a resource.
2. Understand more about how the security picture changes with mobile
applications.
CONTENT
Module 3: A New Architecture
mGovernment 91
Glossary
Sources
CoDI: Center of Digital Innovation.
http://owasp.org
Native Apps
• Address limitations of Mobile Web
• Take advantage of mobile capabilities
• Subject to normal security vulnerabilities, e.g.: OWASP Top Ten
• Also introduces new vulnerabilities
• Lost/Stolen
• Secure Storage
• Secure Interaction with different protocols
• Emergent behavior – new protocols, features: NFC, SMS, MMS, GPS,
• Unclear usage patterns
• Privacy is “the third rail”
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 92
CONTENT
OWASP:
• Is Open Source meaning that it is open to anyone who wants to make a
contribution
• It was started in 2001 and the
• First publication of the standard came out in 2008, as the Application Security
Verification Standard (ASVS) to normalize the requirements for security in the
vendor market
• It now covers mobile as well as web applications
But be mindful that OWASP, like the real world, is always updating, reflecting the
nature of the market, and of the security issues involved.
OWASP is a good resource, and their “Top Ten” lists are indications of common
problems, mistakes, misconfigurations, etc., and of what is being exploited.
The “Top Ten” is periodically revised, so keep checking on it regularly.
Note that the testing performed in the Center of Digital Innovations - CoDI - is
based at least in part on the OWASP Top 10.
With this as background now consider this expanded Attach Surface. New vulner-
abilities come with the mobile platform. Obviously the devices are more prone
to loss or theft, meaning an attacker would have direct physical access to the
device.
Module 3: A New Architecture
mGovernment 93
CONTENT
If the device in question has removable storage, you need to understand the
security properties involved, and that differs from platform to platform.
We cannot predict what the platform (iOS, Android, etc.) developers will include
in new versions, nor can we predict how consumers will use them.
Privacy is of varying concern depending on various factors like societal norms,
the law, etc., but understand this simple observation: information once revealed,
and the Privacy of individuals compromised, cannot generally be restored. We
should always be concerned about privacy even if our users are not (now, yet).
When designing the mobile native app for your government entity, this concern
should be at the top of the list.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 94
1. Get a glimpse of how the mobile server is evolving.
This next slide is a representational diagram of a modern integrated architecture
of a mobile architecture described here as the Mobile Middle Tier A Security
Token Service, or STS. STS is a software based identity provider responsible for
issuing security tokens, especially software tokens, as part of a claims-based
identity system.
In a typical usage scenario, a client requests access to a secure software
application, often called a relying party. Instead of the application authenticating
the client, the client is redirected to an STS. The STS authenticates the client and
issues a security token. Finally, the client is redirected back to the relying party
and presents the security token. The token is the data record in which claims are
packed. The token is protected from tinkering with strong cryptology.
The software application verifies that the token originated from an STS trusted
by it, and then makes authorization decisions accordingly. The token is creating
a chain of trust between the STS and the software application consuming the
claims.
Completing this description we can now start to appreciate some of the inherent
complexity necessary to create the trusted transactions for mobile services in
general and more specifically government mobile services.
CONTENT
Module 3: A New Architecture
mGovernment 95
Glossary
STS: Security Token Service.
Mobile Middle Tier
Mobile “Thingfrastructure” STS CloudProprietary OS, Access control
Token exchange Standards based Access control
Token by reference Resolve artifacts Token by reference & value
Mobile sessions & permissions Constrain and manage sessions for Mobile clients
Cloud sessions & permissions
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 96
LEARNING OBJECTIVES
1. Understand the changes to the architecture required by mGov.
2. Expose the class to Attack Surfaces, discussed in detail later.
3. Expose the class to the high-level differences with mobile applications.
Review the Objectives (re-read the slide).
CONTENT
mGovernment 97
Module 3: A New Architecture
Review of Objectives
• Understand the changes to the architecture required by mGov.
• Expose the class to Attack Surfaces, discussed in detail later.
• Expose the class to the high-level differences with mobile applications.
It is now time to review your knowledge
of this material
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 98
Quiz – Question 1
1. Which of the following is a role of the PMO ?
a. Design new applications for government
services
b. Convert all government services to mobile
c. Establish policies, standards, and best practices
d. Collaborate with stakeholders
Module 1, mGov Training Introduction
mGovernment 99
Module 3: A New Architecture
Quiz – Question 3
Quiz – Question 2
3. What is capacity building ?
a. Working together to achieve the same goals
b. Increasing the ability to serve more customers
c. Understanding what organizations can do for each other
d. A major responsibility of the PMO
2. Which of the following is an example of a
mobile worker ?
a. A restaurant worker
b. A building inspector
c. An office administrator
d. A teacher
mGovernment 1 0 0
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
Module 1, mGov Training Introduction
mGovernment 1 0 1
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 102
CONTENT
We will introduce the concept of an SDLC (defined later) and discuss how its
proper application can begin to address the Structural Problem.
THEMES
• Security, Strategy.
• Business Processes & Collaboration.
Module 1, mGov Training Introduction
mGovernment 1 0 3
Module 4: Addressing the Structural Problem with mGov
Addressing the Structural Problem with
mGov
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 104
This module has these objectives:
1. Introduce SDLC.
2. Understand the common aspects of a Development Lifecycle.
3. Understand that the proper application of an SDLC can help address the
Structural Problem.
Introduce the Objectives, (read the slide).
CONTENT
mGovernment 105
Module 4: Addressing the Structural Problem with mGov
Objectives
• Introduce SDLC.
• Understand the common aspects of a Development Lifecycle.
• Understand that the proper application of an SDLC can help address
the Structural Problem.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 106
1. Introduce a generic SDLC
This is a grossly simplified view of the SDLC. It is provided to conceptualize how
the SDLC is cyclical, and continues to be relevant long after implementation.
The next slide displays a much more detailed analysis of the SDLC, but lacks the
cyclical display of this one.
The “S” can be System, Software or Security. All are relevant, even though this
is the Security track.
In all cases, the SDLCs share two key features, discussed on the next slide,
and the most important thing to understand is the importance of maximizing
involvement of all parts of the team from the beginning.
SDLC: Security, Software or System Development Lifecycle.
Glossary
CONTENT
Module 4: Addressing the Structural Problem with mGov
mGovernment 107
• A cyclical process which establishes the development, maintenance,
& improvement of a system or application
• Determine what you need
• Design a solution
• Implement the solution
• Test to see if it meets needs
• Maintain it, and then…
• Determine what you need
• Design a solution
• Implement the solution
• Test to see if it meets needs
• Maintain it, and then…
• Determine what you need
• Design a solution
Development Life Cycle (SDLC)
https://upload.wikimedia.org/wikipedia/commons/1/19/SDLC_-_Software_
Development_Life_Cycle.jpg
SOURCES
https://upload.wikimedia.org/wikipedia/commons/1/19/
SDLC_-_Software_Development_Life_Cycle.jpg
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 108
1. Understand the two common features of any Development Lifecycle.
There are two common SDLC factors we want to focus on at a high level:
The first common factor is that all SDLCs contain a start point. It is critical to
maximize participation as early as possible in this phase, to build security into the
process from the beginning. This is the only way to attack the structural problem
we discussed previously.
It is critical from a development point of view to achieve and document
agreement on the scope of the project in the beginning phase.
The second common factor is that these cycles typically do not end. Once a
given cycle is complete, a new one begins based on the outcome of the previous
one.
CONTENT
Module 4: Addressing the Structural Problem with mGov
mGovernment 109
• Start Point
• All Development Lifecycles have a beginning, requirements
definition / analysis
• Maximize Participation
• Cyclical
• Development Lifecycles do not typically end
• In all phases, capture:
• Additional Features
• Bugs
• Enhancements
• Etc…..
• Roll these into Requirements for the next Cycle
SDLC Common Features
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 110
1. Identify some of the details of embedding security in each phase of the
SDLC.
Embed security in ALL Phases, but ensure participation from the beginning.
Ensure Security requirements are captured in the beginning with the functional
and other requirements.
Make sure the architecture allows for defense in depth.
In the design phase, build and consider threat models to flesh out the detailed
security requirements.
Use well understood, known secure frameworks when coding, following good,
secure coding practices.
Integrate security testing, including source code analysis, vulnerability
assessment and penetration testing.
CONTENT
Module 4: Addressing the Structural Problem with mGov
mGovernment 111
Address the Structural Problem – Embed security in the
development life cycle
• Requirements gathering
• Define non-functional security requirements, and align with
functional requirements
• Architecture
• Ensure defense in depth coverage and capabilities
• Detailed design
• Build and analyze threat models to generate detailed security
design requirements
• Development
• Implement frameworks and patterns for common security services.
Follow good secure coding practices.
• Testing
• Integrate source code analysis, vulnerability assessment and security
testing
SDLC
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 112
1. Ensure students understand that the mGov transition represents an
opportunity to address the structural problem.
CONTENT
The mGov project, which is really the continuation and evolution of a long
running effort to modernize government in the UAE, represents an enormous
opportunity to address the structural problem.
Lots of infrastructure will be added, will be changing and modernized, and this is
a chance to get security embedded in the process, not applied afterwards as a
band-aid for the structural problem.
mGovernment 113
Module 4: Addressing the Structural Problem with mGov
• Most security activity is treatment, not prevention
• Most treatment applied to symptoms, not the disease
• The disease is poor program code, poor hardware configuration,
and poor architecture design
• mGov presents an unprecedented opportunity to do security prop-
erly from the start, instead of rushing to fix the problems we could
have avoided
• This allows security to participate in development,
instead of inheriting a broken system from the start
Crisis or Opportunity?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 114
The choice is pretty simple, and the analogy here is a good one.
CONTENT
1. Reinforce the opportunity, and the consequences of missing it.
Module 4: Addressing the Structural Problem with mGov
mGovernment 115
Which Do You Want?
7
A gram of prevention? A kilogram of treatment?
• Get involved with your Entity’s mGov plans! NOW!
• Don’t get involved.• Bad code will be written• Bad infrastructure designed• Bad management choices
• You’ll have plenty of work to do in the future, cleaning up the mGov Security messes you could have avoided by starting today.
OR
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 116
Returning back to the discussion from the first security module, learning to think
like a security professional includes learning to place yourself in the mindset of
the attacker.
The Hackers Will attack your systems
The Hackers Will find your weaknesses
The Hackers Will successfully break in
The Hackers Will steal data and sell it
The Hackers Will do it again
The Hackers Will always be there
The Hackers Will never stop
The Hackers Will grow in numbers
Now that you know that, what are you going to do about it?
CONTENT
1. Reinforce from module SC01 that this is the mindset of the attacker, and that
they never stop.
Module 4: Addressing the Structural Problem with mGov
mGovernment 117
Remember…I WILL attack your systemsI WILL find your weaknessesI WILL successfully break inI WILL steal data and sell itI WILL do it againI WILL always be thereI WILL never stopI WILL grow in numbers
What will you do about it?
http://aymcreations.deviantart.com/art/Hacker-343952762
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 118
CONTENT
Review the Objectives (re-read the slide).
1. Introduce SDLC.
2. Understand the common aspects of a Development Lifecycle.
3. Understand that the proper application of an SDLC can help address the
Structural Problem.
Module 4: Addressing the Structural Problem with mGov
mGovernment 119
Review of Objectives
• Introduce SDLC
• Understand the common aspects of a Development Lifecycle
• Understand that the proper application of an SDLC can help address
the Structural Problem
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 120
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 121
Module 4: Addressing the Structural Problem with mGov
Quiz – Question 1
1. It is critical to maximize involvement of all members of the
team at the earliest possible point in the development lifecycle?
Select one:
a. True
b. False
mGovernment 1 2 2
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
Module 1, mGov Training Introduction
mGovernment 1 2 3
mGovernment 1 2 4
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
This short module begins the discussion of several security models / frameworks
and related concepts.
The point of using these is to help shape and structure your thoughts, and
more importantly, when you are discussing security with a colleague, by using a
common model or framework, to allow you to share vocabulary and a frame of
reference, which makes sharing knowledge easier.
CONTENT
THEMES
1. Security, Strategy.
2. Business Processes & Collaboration.
Module 1, mGov Training Introduction
1 2 5125mGoverment
Module 5: Security Frameworks & Models
Security Frameworks
& Models
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 126
This module has these objectives:
1. Introduce Security Goals.
2. Set expectations for the next several modules.
Introduce the Objectives, (read the slide).
CONTENT
mGovernment 127
Module 5: Security Frameworks & Models
• Introduce Security Goals.
• Set expectations for the next several modules.
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 128
1. Introduce Security Goals: CIA
ISO 27000:2009 defines Information Security as the “Preservation of
confidentiality, integrity and availability of information. “
This is a classic definition, and could be expanded, but these are the basics we
want to keep in mind as our goals.
In detail:
InfoSec “Ensures that only authorized users (confidentiality) have access to
accurate and complete information (integrity) when required (availability).”
(ISACA, 2008)
CONTENT
mGovernment 129
CONFIDENTIALITY
INTEGRITY
AVAILABILITY
Glossary
Module 5: Security Frameworks & Models
The Goals are C.I.A.
ISO 27000:2009: ISO Standard: Information technology - Security techniques -
Information security management systems - Overview and vocabulary.
ISACA: an international professional association focused on IT Governance.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 130
1. Set the stage for the following several modules.
We will cover, (or covered in a previous module) each of these briefly. These
are aids to help you structure your thinking, and communicate about security
effectively.
CONTENT
mGovernment 131
Module 5: Security Frameworks & Models
Tools in the Toolbox
• SDLC (Discussed earlier)
• OWASP
• STRIDE
• Attack Surface Modeling
• Static & Dynamic Analysis
• Penetration Testing
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 132
1. Introduce Security Goals.
2. Set expectations for the next several modules.
Review the Objectives (re-read the slide).
CONTENT
mGovernment 133
Module 5: Security Frameworks & Models
Review of Objectives
• Introduce Security Goals
• Set expectations for the next several modules
It is now time to review your knowledge
of this material
QUIZ
Quiz – Question 1
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 134
• Match the following Goals with their definitions:
6
Goals:
A. Confidentiality
B. Availability
C. Integrity
• Information is available when required.
• Information is accurate and complete.
• Only authorized users have access to the information.
Module 1, mGov Training Introduction
mGovernment 135
Module 5: Security Frameworks & Models
Quiz – Question 2
2. What is a security goal?
Select one:a. Confidentiality – keeping information secret
b. Integrity – prevent and detect tampering
c. Availability – ability to access and use resources
d. All of the above
mGovernment 1 3 6
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 1 3 7
mGovernment 1 3 8
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
This module introduces the first of several security models/ frameworks,
OWASP, or the Open Web Application Security Project. Again, the point of using
frameworks and models is to help shape and structure your thoughts, and
more importantly, when you are discussing security with a colleague, by using a
common model or framework, to allow you to share vocabulary and a frame of
reference, which makes sharing knowledge easier.
CONTENT
THEMES
• Security.
OWASP
Glossary
Module 6: OWASP Open Web Application Security Project
OWASPOpen
Web Application Security Project
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 140
This module has these objectives:
1. Introduce OWASP.
2. Explore several of the OWASP Top 10 Mobile security risks.
3. Get students in the habit of referring to external sources (in this case OWASP)
for details of complex topics.
Introduce the Objectives, (read the slide).
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 141
• Introduce OWASP.
• Explore several of the OWASP Top 10 Mobile security risks.
• Get students in the habit of referring to external sources (in this case
OWASP) for details of complex topics.
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 142
1. Discuss OWASP as resource.
OWASP is a great resource. How many of you are aware of it in the Web world?
They also “do mobile”, so take advantage…
From their web site: “The Open Web Application Security Project (OWASP) is a
501(c)(3) worldwide not-for-profit charitable organization focused on improving
the security of software. Our mission is to make software security visible, so that
individuals and organizations worldwide can make informed decisions about
true software security risks. “
They provide a “Top 10” list of risks or vulnerabilities for web applications, and
now they are providing something similar for mobile applications, which is
natural as Internet applications transition from web-based to our mobile devices.
Think of these Top 10 lists as mistakes that others have made. Making you
aware of them makes it easier for you to avoid repeating them.
If (when) you take your mGov app to the CoDI for testing, know that the OWASP
Top 10 is one of the things they strive to test for.
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 143
SOURCES
http://owasp.org
OWASP Mobile Top Ten
• There is a standardized
way to organize your
approach to Security
by Design
• (Revisit the Top 10, as they are
periodically revised)
• IF you see a test question on
OWASP, refer to the current
Top 10 on the web site……
mGovernment 1 4 4
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
The composition and order of the 10 change periodically for various reasons, so
it’s wise to stay aware of them as they shift, or when answering a test question.
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 145
OWASP Mobile Top Ten
• There is a standardized
way to organize your
approach to Security
by Design
• (Revisit the Top 10, as they are
periodically revised)
• IF you see a test question on
OWASP, refer to the current
Top 10 on the web site……
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 146
1. Understand that secure storage, particularly removable storage, is an issue.
Sensitive data ends up on mobile devices, in RAM, in on-board and removable
storage. This data will not encrypt or protect itself, so a lot of the issues related
to Insecure Storage come down to poor assumptions on the part of developers,
or outright self-inflicted wounds.
A prime example are the removable SD cards in common use on platforms other
than iOS. These are almost always formatted with FAT, the old File Allocation
Table, which has NO permission or protection model. This means if the attacker
gets the card, unless the application which wrote to it encrypted it, the data it
contains is exposed.
Mobile devices to get lost, stolen, left on busses, trains, airplanes, in taxis, etc., so
we loose the physical layer of protection. We MUST be aware of and address this.
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 147
Glossary
Sources
RAM: Random Access Memory.
SD Card: Secure Digital Card.
FAT: File Allocation Table.
http://owasp.org
Insecure Storage
A problem on mobile for two reasons
• Many apps store data locally for performance, session cache and
other reasons
• Devices get lost and stolen, sometimes with sensitive data on them
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 148
1. Understand the basics of buffer overflow bugs.
A buffer overflow is a name for a common class of vulnerabilities.
In this simple example in the “C” programming language, the code block on the
left has a problem, the one on the right not so much.
On the left, the code:
• Declares a variable called “text” of type “char”, 100 bytes long
• Prompts the user to “Enter Text”
• Reads input from the user into the variable text using the scanf function.
The problem is that there is no check or limit on the size of the data being read
in with scanf. If more than 100 bytes come in, they will overflow the input buffer
and be written into memory.
An attacker will search for and find these flaws, inject his malicious payload into
a memory location of his choice by adjusting the length of the input, and cause
your program to crash (at best), or to execute his code (bad).
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 149
http://owasp.org
https://en.wikipedia.org/wiki/Buffer_overflow
Sources
Buffer Overflow
• The program copies an input buffer to an output buffer without
verifying that the size of the input buffer is less than the size of the
output buffer, leading to a buffer overflow.
char text[100];
printf (“Enter text: “);
scanf (“%s”, text);
char text[100];
printf (“Enter text: “);
scanf (“%99s”, text);
mGovernment 1 5 0
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
CONTENT
On the right, the code:
• Declares the variable and prompts the user as before
• Reads input as before, but now limits what is read in to 99 bytes so that it plus
the NULL terminator will fit in the declared 100 byte variable space.
This is an extremely common type of programming error that honestly results
from lazy programmers, or from programmers who were not taught secure
coding practices.
It may be detected by source code analysis, or dynamic testing, but it’s easier to
just prevent the poor coding in the first place.
Note that some languages like Java are built to prevent these types of problems
from the beginning.
mGovernment 151
Module 6: OWASP Open Web Application Security Project
Buffer Overflow
• The program copies an input buffer to an output buffer without
verifying that the size of the input buffer is less than the size of the
output buffer, leading to a buffer overflow.
char text[100];
printf (“Enter text: “);
scanf (“%s”, text);
char text[100];
printf (“Enter text: “);
scanf (“%99s”, text);
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 152
1. Begin to understand the class of issues associated with improper session
handling.
State machines are tricky, particularly with stateless protocols like http, or with
asynchronous connections, long-lived connections, and frequent disconnects, all
of which come along with moving applications to mobile.
I invite you to explore this in detail from OWASP, but the end result of exploitation
of this class of vulnerability normally results in a hijacked session, allowing the
attacker access to a user’s data, or to elevate privilege, or both.
Using the device ID as a session token is a rookie mistake. Don’t make it, or let
your developers make it.
CONTENT
mGovernment 153
Module 6: OWASP Open Web Application Security Project
• Mobile session differences
• Usability, connections
• Sessions – HTTP cookies, oauth tokens, SSO tokens
• Vuln 0 is using device ID as session token
• Impact
• Privilege escalation
• Unauthorized access
• Circumvent licensing and payments
Improper Session Handling
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 154
The notion of a an Untrusted Input rises from the programming practice of
accepting input from an exterior source blindly and using it without validating it
to make sure it is as expected.
At a minimum, that means the data is of the expected type and length, and does
not contain inappropriate characters.
For example, a login ID field should only accept text, of the maximum length of
the LoginID, and reject any special characters or reserved programming words.
A Login ID field is not an appropriate place for text like:
Select * from users;
Which is a SQL command, complete with semicolon, that just might dump the
entire user table.
Some of these attacks take nothing more than the URL bar of a browser to
explore or execute, so they are particularly dangerous.
Bottom line is that Programmers MUST validate all input.
CONTENT
1. Understand that programmers should never trust un-validated inputs.
mGovernment 155
Security Decisions via Untrusted Inputs
• Bypass permission and security models
• Examples
• iOS abusing URL schemes
• Android abusing intents
• Vectors
• Malicious apps
• Client side injection
• Impacts
• Consuming paid resources
• Data Exfiltration
• Privilege escalation
SOURCES
http://owasp.org
Module 6: OWASP Open Web Application Security Project
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 156
1. Begin to understand data leakage.
One thing is certain, data that has “leaked”, or which is not in an expected
location, is not under scrutiny (at least not by the good guys) and is not being
protected.
Let’s look at one very specific example of potential data leakage, on the iPhone.
Think of the following scenario: You are entering some text in an application on
your phone, and the phone rings. Immediately, the iPhone switches the screen
to the phone screen, where you either take or reject the call.
When finished with the call screen, the iPhone immediately switches you back
to where you were in the previous application. If this has happened to you, and
paid close attention, you might have noticed that upon returning to the original
app, it was not immediately responsive, even though you could see it on screen.
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 157
Side Channel Data Leakage
SOURCES
http://owasp.org
• Causes: a mix of not disabling platform features and programming
flaws
• Results in Sensitive data in unintended places
• Web cache
• Keystroke logging
• Screenshots (iOS backgrounding)
• Logs (system, crash)
• Temp directories
• Impacts
• Data retained indefinitely
• Privacy violations
mGovernment 1 5 8
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
CONTENT
The reason is that when iOS make a switch as described, it takes a screenshot
of the original app, and upon return, displays the screenshot while it does the
full context switch to the app.
Now, ask yourself:
• Were you entering sensitive data that might have been captured on the
screenshot?
• Where was / is that screenshot stored?
• Is / was it encrypted?
• What else has access to it?
• Was it wiped? Securely?
This is potential data leakage through a side channel.
Again, read the details on this and the other examples of the Top 10 we
mentioned, plus the rest of the current Top 10 from OWASP.
There are other good resources at OWASP to help understand the issues, as
well as help learn how to test for them.
Module 6: OWASP Open Web Application Security Project
mGovernment 159
Side Channel Data Leakage
• Causes: a mix of not disabling platform features and programming
flaws
• Results in Sensitive data in unintended places
• Web cache
• Keystroke logging
• Screenshots (iOS backgrounding)
• Logs (system, crash)
• Temp directories
• Impacts
• Data retained indefinitely
• Privacy violations
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 160
1. Introduce OWASP.
2. Explore several of the OWASP Top 10 Mobile security risks.
3. Get students in the habit of referring to external sources (in this case
OWASP) for details of complex topics.
Review the Objectives (re-read the slide).
Let me emphasize that 3d objective. It’s very important to teach you where to go
for critical information, and to build the habit of going there.
CONTENT
Module 6: OWASP Open Web Application Security Project
mGovernment 161
Review of Objectives
• Introduce OWASP
• Explore several of the OWASP Top 10 Mobile security risks
• Get students in the habit of referring to external sources (in this
case OWASP) for details of complex topics
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 162
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 163
Module 6: OWASP Open Web Application Security Project
Quiz – Question 1
1. OWASP never revises their “Top 10” lists or any of their other
resources, so one visit to their web site should be enough for the
duration of a project?
Select one:
a. True
b. False
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
1 6 5
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 166
CONTENT
This module introduces the STRIDE threat model and continues the introduction
of Attack Surface Modeling.
• Security.
THEMES
• Accessed through the web browser
• Deployed over Internet
• Can develop/design one application for all platforms
• A cross-platform mobile application
• Provides uniformity across all platforms
• Near-instant updates
• Updates to the application are actually updates to the website,
happening on the back-end
Introduction
Module 7: STRIDE & Attack Surface Modeling
SDLC: Service Delivery Lifecycle
Glossary
mGovernment 167
STRIDE
&
Attack Surface
Modeling
Module 7: STRIDE & Attack Surface Modeling
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 168
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Introduce STRIDE and basic countermeasures.
2. Continue exploration of Attack Surface Modeling.
Module 7: STRIDE & Attack Surface Modeling
mGovernment 169
Objectives
• Introduce STRIDE and basic countermeasures.
• Continue exploration of Attack Surface Modeling.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 170
STRIDE is a vulnerability or threat model invented and in wide use by Microsoft
and across the industry. They find it valuable for modeling the threats and then
proposing countermeasures.
It identifies six types of threats. As you can see, STRIDE is an acronym which
stands for:
• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege
You will probably note some overlap with our security goals of CIA,
Confidentiality, Integrity and Availability, but these are more specific.
Further, CIA represents goals, STRIDE represents threats.
CONTENT
1. Introduce and explore STRIDE.
Module 7: STRIDE & Attack Surface Modeling
mGovernment 171
STRIDE Threat Model
Threat Description Example
SpoofingAssume identity of client, server or request/response
Phishing attack to fool user into sending credentials to fake site
TamperingAlter contents of request of response
Message or data integrity compromised to change parameters or values
RepudiationDispute legitimate transaction Illegitimately claiming a
transaction was not completed
Information DisclosureUnauthorized release of data Unencrypted message sniffed
off the network
Denial of ServiceService not available to authorized users
System flooded by requests until web server fails
Elevation of privilegeBypass authorization system Attacker changes group
membership
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 172
Spoofing occurs when an attacker assumes the identity of subject (like user or
client), object (like a server, web application or database), or account. Phishing is
an example of Spoofing where an attacker fools the user by spoofing a legitimate
site like an online bank and tricks the user into sending their username and
password to a site the attacker controls. It is also possible for an attacker to spoof
the identity of the user directly.
Tampering occurs when message or data is altered by the attacker.
Repudiation occurs when the attacker denies an authentic event such as
claiming that an ATM machine did not give any money when in fact the attacker
did receive money from the ATM.
Information may be disclosed in number of ways; information can be sniffed
off of a network communication channel, such as through packet sniffing
unencrypted networks. Attackers may actively try to gather information through
injecting SQL commands to the database.
Denial of Service (also sometimes called “Denial of business”) means an attacker
can swamp the system to deny access to legitimate users.
Elevation of privilege occurs when an attacker finds a way to bypass access
control that limits their privileges. An attacker may try to elevate privilege by
using a normal account to run commands that are administrator only.
CONTENT
Module 7: STRIDE & Attack Surface Modeling
mGovernment 173
CONTENT
This is a brief overview of the STRIDE threat model, and on the next slide, we
will look at how countermeasures can be identified based on these threats.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 174
CONTENT
The value of threat modeling is to assist with building security into the design.
Specifically, the threat model gives a concrete set of requirements and location
of the countermeasure in the system.
For the six threats in STRIDE that we briefly introduced, each could be mitigated
by a different countermeasure.
This list is illustrative not exhaustive; the purpose is to see that each threat will
likely yield different security mechanisms
Spoofing threats such as when an attacker impersonates a user, client or server,
may be mitigated by authentication mechanisms which verify the authenticity of
the subjects, objects and users.
Tampering threats such as altering data may be mitigated by signing and
hashing data to verify the integrity of the data.
Repudiating legitimate transactions may be mitigated through an audit log that
contains evidence of the transaction.
1. Understand how analyzing the threats helps us select appropriate
countermeasures.
Module 7: STRIDE & Attack Surface Modeling
mGovernment 175
Countermeasures
Threat Security ServiceSpoofing AuthenticationTampering Digital Signature, HashRepudiation Audit LoggingInformation Disclosure EncryptionDenial of Service AvailabilityElevation of privilege Authorization
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 176
Information disclosure can occur in many ways. For example, the threat of
sniffing information off the wire, can be mitigated by encryption.
Denial of service is mitigated through availability services like clustering, and fail
over, and by careful planning.
Elevation of privilege is mitigated through authorization checking to see if the
user has the correct rights to access the system.
This table is a good example of the value of threat modeling. It shows that
security is not one thing or one mechanism. Rather security can be defined as a
set of mechanisms that cope with certain threats. Depending on which threats
the system designers are trying to mitigate, the threat model will yield different
guidance for which mechanisms are necessary.
CONTENT
Module 7: STRIDE & Attack Surface Modeling
mGovernment 177
Countermeasures
Threat Security ServiceSpoofing AuthenticationTampering Digital Signature, HashRepudiation Audit LoggingInformation Disclosure EncryptionDenial of Service AvailabilityElevation of privilege Authorization
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 178
CONTENT
Attack surface Modeling is a way of thinking developed by Microsoft and
Carnegie Mellon University. It is really a refinement and application of some very
old military techniques to information security.
The core ideas here are that careful analysis can reveal where you can get
attacked, and sometimes how. It tells you what you must monitor to detect an
attack, and helps you prioritize your defensive efforts
The Attack Surface consists of:
• Data
• Method
• Channel
Here are some specific examples if the Mobile Attack Surface listed on the slide.
1. Understand the basics Attack Surface Modeling.
Module 7: STRIDE & Attack Surface Modeling
mGovernment 179
Attack Surface
• Developed at Microsoft and Carnegie Mellon
• Not really a New Idea….
• Describes the locations an attacker can launch, propagate and
detonate an attack
• The Attack Surface consists of: Data + Method + Channel
• Example Mobile Web Service Attack Surfaces:
• Data: JSON, XML, HTML5
• Method: HTTP, URI
• Channel: HTTP
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 180
CONTENT
Consider the examples listed under Data, Method and Channel on the slide.
Remember the changes to the n-tier architecture diagrams in the eGov and
mGov cases?
It’s pretty intuitive that when we move the front end of the application out of
the datacenter and into a handheld or mobile device, that the Attack Surface
has changed.
Analysis of the Attack Surface in both cases can help the attacker organize and
plan his offensive efforts. We do the same things to understand how he will try
and attack, therefore what we must defend.
1. Continue the Attack Surface discussion with some Mobile specifics.
Module 7: STRIDE & Attack Surface Modeling
Glossary
mGovernment 181
Mobile Attack Surface
Mobile Attack Surface analysis creates (exposes?) numerous challenges
BLE: Bluetooth Low Energy.
NFC: Near Field Communications.
• Data
• Application, standard & proprietary
• Can be stored inadvertently, e.g. backgrounding
• Method
• Some app methods are black box
• Synthetic methods, asychronous applications
• Communications channel
• Not just HTTP
• SMS/MMS, NFC, GPS, BLE, and more
• Inbound communications - Push notifications
• Difficulty in testing
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 182
Review the Objectives (re-read the slide).
CONTENT
1. Introduce STRIDE and basic countermeasures.
2. Continue exploration of Attack Surface Modeling.
Module 7: STRIDE & Attack Surface Modeling
mGovernment 183
• Introduce STRIDE and basic countermeasures.
• Continue exploration of Attack Surface Modeling.
Review of Objectives
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 184
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 185
Module 7: STRIDE & Attack Surface Modeling
Quiz – Question 1
1. What Threats are included in the STRIDE Threat Model?
Select one or more:
a. Spoofing
b. Tampering
c. Repudiation
d. Integrity
e. Denial of Service
f. Elevation of Privilege
1 8 6
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
1 8 7
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 188
This module introduces several different types of security testing, and provides
some real-world examples of vulnerabilities that were or should have been
discovered through testing.
CONTENT
THEMES
• Security, Applications.
Module 1, mGov Training Introduction
mGovernment 1 8 9
Module 8: Analysis & Testing
Analysis &
Testing
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 190
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Discuss Static Analysis.
2. Discuss Dynamic Analysis.
3. Discuss Penetration Testing.
4. Provide some Real-World Examples.
Module 8: Analysis & Testing
mGovernment 191
Objectives
• Discuss Static Analysis.
• Discuss Dynamic Analysis.
• Discuss Penetration Testing.
• Provide some Real-World Examples.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 192
CONTENT
This slide attempts to make it clear that no one method will find all
vulnerabilities, and that there will be overlaps, and gaps.
For projects where you are creating code, or managing the coding, you should
ALWAYS perform static analysis, mostly because you can.
You have the source code, which is a requirement.
As a side note, if you have contracted out development or portions of the
development of your applications, make sure that you secure the source code
as a deliverable, so that you can perform static analysis, or contract that out.
Perform Dynamic testing to the extent that you can. You may be limited here by
the availability of tools, or the budget to buy them.
Penetration testing should also be performed, but we will discuss some limitations
and expectations later.
1. Understand that no testing method is a direct replacement for another, and
that none will find all vulnerabilities.
Module 8: Analysis & Testing
mGovernment 193
Finding Coding Weaknesses
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 194
Static analysis can and should start with manual peer review of the code by the
developers during the development process, and continue with independent
testing, preferably with high quality commercial or potentially free software
review tools. The commercial ones can be expensive, so leverage the CoDI at
the TRA in Dubai.
They have tools and automated testing which is available to mGov team
members at no charge.
Note that you have to have the source code to do this in a traditional way, but
that attackers will decompile your binaries for this purpose, so you can never
assume that the bad guy isn’t going to read your code, and everything in it.
That means embedding things in code (hard-coded urls, account names,
passwords, etc) is an exceedingly bad idea. You can embed it you cannot
hide it.
Explore the code example above……
<CLICK>
CONTENT
1. Introduce static analysis with a simple example.
Module 8: Analysis & Testing
mGovernment 195
Static Analysis
• Security-themed Code Review.
• Doesn’t execute the code – finds most of the flaws.
• Usually performed by automated tools.
Simple example:
function isAdministrator(permissionLevel){
if (permissionLevel > 2)
return true;
if (permissionLevel < 2)
return false;
}
• What happens if permissionLevel equals 2?
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 196
What will happen if permissionLevel = 2 ? It’s not clear, is it?
That is exactly the problem, what WILL the machine do if permissionLevel = 2 ?
We do not know, which is not an acceptable outcome in the security world.
CONTENT
Module 8: Analysis & Testing
mGovernment 197
Static Analysis
• Security-themed Code Review.
• Doesn’t execute the code – finds most of the flaws.
• Usually performed by automated tools.
Simple example:
function isAdministrator(permissionLevel){
if (permissionLevel > 2)
return true;
if (permissionLevel < 2)
return false;
}
• What happens if permissionLevel equals 2?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 198
Let’s look at a simple two line block of C code. <CLICK>
To begin, you have to understand a little about Boolean logic and the way
expressions are evaluated.
When you evaluate a statement like “if (A and B)”, first the truth of “A” is tested,
and the statement is automatically false if A is false; B never gets evaluated in
that case. If A is true, then the second condition, B is tested.
OR’s are parsed similarly, except only one side of an OR has to be true for the
statement to be true, so if the first is true, the second will not be evaluated. If it
is false, the second side will be.
In this example, we test if “options” are “_WCLONE” or “_WALL”. The “==”
operator in C is a test for equality, the “ | “ operator for OR. Assume one is true.
Then we test the right side of the AND test, “&&” is the operator for AND in C.
CONTENT
1. Understand how a simple typographical error, uncaught, can result in a
critical security failure.
Module 8: Analysis & Testing
mGovernment 199
Real World Example
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))retval = -EINVAL;
ASSIGNMENT!NOT EVALUATION!
If not discovered, this code would execute when called in a very specific manner.
The uid 0 belongs to root.
Opening this backdoor would grant unrestricted administrator access to the system.
Don’t worry, it was discovered before the kernel was published.
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 200
Remember, both sides of an AND must be true for the test to be true, so if the
first condition is true, and we have assumed it is, the second will be evaluated.
<CLICK>
The right side of the && operator is “current->uid = 0”, <CLICK>
but that single “=” is not a test of equality, it is an assignment. It SETs the current
user id (uid) to “0”, which assigns the root identity to whoever runs this code and
with options == _WCLONE or _WALL
This is a textbook example of a root level elevation of privilege threat (remember
the E in STRIDE) that resulted probably as a because of a simple typographical
error.
<CLICK>
This was caught at the last minute before this code was integrated into the linux
kernel via static analysis.
CONTENT
Module 8: Analysis & Testing
mGovernment 201
Real World Example
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))retval = -EINVAL;
ASSIGNMENT!NOT EVALUATION!
If not discovered, this code would execute when called in a very specific manner.
The uid 0 belongs to root.
Opening this backdoor would grant unrestricted administrator access to the system.
Don’t worry, it was discovered before the kernel was published.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 202
Let’s introduce the Heartbleed vulnerability, which should have been discovered
through static analysis, but was actually discovered through a testing technique
call fuzzing, which we will discuss later.
For those of you who are very technically minded, I refer you to the URL on the
slide, where this is explored and explained in detail. Alternatively, refer to the
CVE listing.
An explanation follows in the next three slides, but essentially, a coding flaw
(a buffer over-read) in the implementation of the optional heartbeat functionality
in OpenSSL results in leakage of information, and eventually total defeat of the
protection, and compromise of the systems.
Heartbleed was independently discovered by several research teams, but the
vulnerability was disclosed by Google on 1 April 2014. The date of the release
caused some issues, as some readers initially thought it was an April Fools Joke.
CONTENT
1. Introduce the Heartbleed Vulnerability.
Module 8: Analysis & Testing
mGovernment 203
Glossary
SOURCES
Heartbleed (CVE-2014-0160)
• Announced by Google Security Team on
April 1st, 2014
The date created some confusion
• Exploits poorly written OpenSSL code
http://www.heartbleed.com
Another Real World Example: HeartBleed
CVE: Common Vulnerabilities and Exposures.
https://cve.mitre.orghttp://www.heartbleed.com
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 204
Glossary
TLS: Transport Layer Security.
DTLS: Datagram TLS.
The optional heartbeat extension to TLS / DTLS provides a way to test and
keep alive secure communication links without the need to renegotiate the
connection.
The requestor sends a message containing a random payload, and the length of
the payload.
The responder should reply with the same random payload, proving that it is
alive.
CONTENT
1. Explain the Mechanics of the vulnerability and the exploit.
Module 8: Analysis & Testing
mGovernment 205
HeartBleed
SOURCES
http://xkcd.com/1354/
Source: http://xkcd.com/1354/
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 206
RFC: an IETF standards document.
IETF: Internet Engineering Task Force.
Glossary
The way the heartbeat extension is supposed to work is spelled out in RFC
6520. Hackers sometimes read RFCs, but they don’t always follow the rules, and
implementations are sometimes not perfect.
CONTENT
1. Continue to explain the Mechanics of the vulnerability and the exploit.
Module 8: Analysis & Testing
mGovernment 207
HeartBleed (2)
SOURCES
http://xkcd.com/1354/
Source: http://xkcd.com/1354/
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 208
So the hacker thinks….. “what if I send a payload of length 3, but tell the responder
that the length is 500?”
A vulnerable server does not check that the length in the request matches
the actual random payload. It replies with the specified random payload, then
over-reads the buffer and sends the requested number of bytes from memory,
up to 64k.
This allows an attacker to read the memory on the server, 64k at a time, and can
leak almost anything.
CONTENT
1. Continue to explain the Mechanics of the vulnerability and the exploit.
Module 8: Analysis & Testing
mGovernment 209
HeartBleed (3)
Source: http://xkcd.com/1354/
SOURCES
http://xkcd.com/1354/
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 210
All versions of OpenSSL from the initial release of version 1.01 through 1.0.1f
have this flaw, and the heartbeat option is on by default.
You should test to see if your code is vulnerable. A list of services which do that
is at the URL provided.
CONTENT
1. Continue to explain the Mechanics of the vulnerability and the exploit.
Module 8: Analysis & Testing
mGovernment 211
• Heartbleed (CVE-2014-0160)
• OpenSSL versions 1.0.1 through
1.0.1f are vulnerable
All other versions are safe
• Heartbleed Vulnerability Testing
Services List:
http://en.wikipedia.org/wiki/Heart-
bleed#Vulnerability_testing_services
HeartBleed (4)
http://en.wikipedia.org/wiki/Heartbleed#Vulnerability_testing_services
SOURCES
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 212
The heartbeat extension can work in either direction, so a server can request
a heartbeat from a client, like a mobile device. This can result in a “reverse
heartbleed”.
Android uses OpenSSL, and android devices with version 4.1.1 have the flaw.
Google has fixed this problem in subsequent versions, but many vendors have
not supplied patches or updates to the older version of Android. Some continue
to sell it.
As an exercise, those of you with Android devices should check the version, and
if you are vulnerable, check with your vendor for an update.
For the record, iOS was never vulnerable to this issue.
CONTENT
1. Continue to explain the Mechanics of the vulnerability and the exploit.
2. Emphasize how widespread this problem IS, and that it will be with us until
vendors, including handset manufacturers provide fixes.
Module 8: Analysis & Testing
mGovernment 213
“Reverse Heartbleed” • “Heartbeats” can be requested
from mobile devices
Android JellyBean 4.1.1 IS
AFFECTED & REMAINS UNPATCHED
• About 50 million devices
• Device Manufacturers are
responsible for issuing patches
• Will they? Ever?
iOS was never affected
HeartBleed (5)
Source: http://gadgets.ndtv.com/internet/news/android-411-devices-vulnerable-to-heartbleed-bug-says-google-508262
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 214
CONTENT
Unlike static analysis, which looks at the source code, dynamic analysis looks at
the running environment. All you need is access to the device, or access to the
API on the backend, and you can test.
There are a number of techniques for this, free and commercial tools. The tools
for the mobiles themselves are behind the rest of the testing community, but
this is changing. Again, leverage the CoDI as they are acquiring and evaluating
the testing tools, and making them available for mGov team use.
DO test against the production versions of your code, as in the same code
version.
DO NOT test against the production environment without exercising extreme
care.
1. Introduce Dynamic Analysis
Module 8: Analysis & Testing
Glossary
mGovernment 215
CoDI Provides:
• Static Analysis Testing (correct).
• Dynamic Analysis Testing (correct).
• Penetration Testing.
• Reviews client-side (device) and server-side (back end) code while it
is running
• Mimics how a hacker would attack the app through a direct device
connection or the back end’s internet accessible interfaces
• Dynamic analysis tests that are created without careful planning
may negatively impact the application’s performance or behavior,
since the application is operating during the test
If you are performing these tests against a non-production version of
your app, they are irrelevant
Dynamic Analysis
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 216
Fuzzing is a dynamic analysis technique whose goal is to identify vulnerabilities.
It works by injecting randomized or malformed data into the target asset’s inputs.
Note that Fuzz testing does not require access to the source code.
Asset identification is the beginning of the Fuzz testing lifecycle, because these
asset “targets” are the place the fuzz tests will deployed against. An asset could
be any node in the application chain from the front end in the mobile device to
the back end in the data center, and all points in between.
The asset provides the target of the fuzzer – where the fuzzed data and events
will be directed.
Vulnerabilities are weak points that an attacker can exploit against an Asset.
HeartBleed was discoverable via static analysis, and should have been found that
way. In reality, it was discovered through fuzzing.
CONTENT
1. Introduce Fuzzing..
Module 8: Analysis & Testing
mGovernment 217
https://www.owasp.org/index.php/Fuzzing
http://www.ibm.com/developerworks/library/j-fuzztest/index.html
SOURCES
• Fuzz testing finds vulnerabilities
• Inject Random data into module inputs
• Does NOT require access to source code
Fuzzing – What is it?
https://www.owasp.org/index.php/Fuzzing http://www.ibm.com/developerworks/library/j-fuzztest/index.html
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 218
If you don’t perform testing of your systems, including dynamic analysis, the
hackers will do it for you, or it will happen by accident. Here’s an example of the
later.
This is the USS Yorktown, and in 1996 it was the test platform for the US
Navy’s Smart Ship program. Smart Ships were modernized and controlled by a
networked set of Windows NT servers and workstations.
While on sea trials in 1997, aboard this ship, a sailor entered a “Zero” somewhere
unexpected. The software accepted it, Unvalidated, and passed it on where it
eventually wound up as a divisor in a mathematical operation.
Divide by zero is an undefined operation in mathematics, and in this case, the
exception that the zero divide generated was not handled gracefully.
The system crashed, the crash cascaded to other systems across the ship, which
lost power and control.
The Yorktown had to be towed back to port.
CONTENT
1. Demonstrate how testing can prevent operational disasters in the real world.
Module 8: Analysis & Testing
mGovernment 219
USS Yorktown
• Testing platform for the US Navy’s “Smart Ship” program in 1996.
• State of the art Windows NT 4.0 & fiber optics installed to show how
technology could improve the “modern US Navy”.
Real World Fuzz Example
• In 1997, a crew member enters 0
into a database
• This caused a “Divide by zero”
error, which shut down all of the
ship’s systems.
• The USS Yorktown had to be
towed back to dock
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 220
A Penetration test, or PenTest is an intentional attack on a system with the intent
to discover vulnerabilities.
Hackers will PenTest your applications and back ends for you, and they will
exploit your vulnerabilities.
In a perfect world, you will already have performed your own PenTest. CoDI and
the aeCERT can assist you with this.
PenTests are usually labeled “white box”, or “black box”. With a white box test,
you supply the attacker with complete information about the target. In the black
box scenario, the attacker starts with little to no information, maybe as little as
the name of the target.
A black box test is more realistic, but less likely to uncover flaws. If budget
permits, perform both, preferably with independent teams.
A positive result means that some flaws were discovered, and can be addressed.
You do not know if you found them all.
CONTENT
1. Introduce Penetration Testing.
2. Understand the limitations of penetration testing
Module 8: Analysis & Testing
mGovernment 221
• Penetration Testing (“PenTest”): an intentional attack on an appli-
cation or system to test and assess its vulnerabilities
• White vs Black:
• “White Box” – All background information about the target is known
or provided
• “Black Box” – Little or no information is provided
• Positive results: flaws uncovered, corrected
• Negative results: unknown whether no flaws exist, or if they were
simply not found
Penetration Testing
CONTENT
A negative result reports no flaws. Does that mean none exist, none were found
for whatever reason, or that no testing was actually performed?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 222
We expose these terms “white vs black vs grey” to make you aware of how they
are used in the industry.
The terms “Black Hat” and “White Hat” have their origins in the old Hollywood
western films. Good guys wore white hats, bad guys wore black. Grey is a mixture
of the two colors.
The label “White Hat Hacker” is supposed to mean that the person is ethical, and
that you can trust them.
A “Black Hat” is an attacker.
A “Grey Hat” is someone you are not sure about, or someone who fits both roles.
The bottom line is this: Hackers explore and break things. Hackers who do this
for you, with your knowledge and permission can help you. Hackers doing it
without your knowledge or permission are simply criminals.
CONTENT
1. Expose the labels applied to hackers.
2. Understand the challenge of finding and selecting an ethical hacker, or Pen
Tester
Introduction
Module 8: Analysis & Testing
mGovernment 223
CONTENT
Hacker Descriptions:
• White hat – “Ethical Hackers” that specialize in professional
security assessment & PenTesting
• Black hat – “Malicious Hackers” that break into systems for
personal gain and/or political reasons (“hacktivism”)
• Grey hat – A mix of white and black hat. May be a professional
“white hat” and a “black hat” as a hobby
Hire a “White hat” to PenTest your
app before a “Black hat” does it with
malicious intent.
Needless to say, it is vitally important that you choose your white hats, or
PenTesters carefully, and monitor their activities. It is best to stay with
well-known professional organizations like commercial firms or government
entities as opposed to working with individual, independent practitioners.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 224
In 2013, Target got a “PenTest” from a helpful gang of hackers that resulted in
the compromise of 40 million payment cards.
We will never know if a professional penetration test would have exposed this
vulnerability before it was exploited, but it is extremely likely that it would have.
In any case, Target had not performed one, even though it is a requirement of
the PCI DSS, and they were theoretically compliant.
CONTENT
1. Understand how failure to test can result in operational disasters in the real
world.
Module 8: Analysis & Testing
mGovernment 225
PCI DSS: Payment Card Industry Data Security Standard
Glossary
Target Corporation
• Announced in December 2013 that approximately 40 million credit
cards were compromised.
• Malicious code exploited a known vulnerability on unpatched
Windows systems.
• Target’s CIO resigned.
• CIO had no IT experience
• The PCI mandated PenTest
was not performed
Real World Penetration
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 226
Review the Objectives (re-read the slide).
CONTENT
1. Discuss Static Analysis.
2. Discuss Dynamic Analysis.
3. Discuss Penetration Testing.
4. Provide some Real-World Examples.
mGovernment 227
Module 8 : Analysis & Testing
• Discuss Static Analysis
• Discuss Dynamic Analysis
• Discuss Penetration Testing
• Provide some Real-World Examples
Review of Objectives
It is now time to review your knowledge
of this material
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 228
Quiz – Question 1
1. Static Analysis requires the tester to have, or to gain, access to the
source code?
a. True
b. False
Module 1, mGov Training Introduction
mGovernment 229
Module 8: Analysis & Testing
Quiz – Question 3
Quiz – Question 2
3. Fuzzing is used for:
Select one:
a. Checking for the robustness of the application at run time
b. Static analysis of the source code
c. Dynamic analysis of your application
d. None of the above
e. A and C
2. CoDI Provides:
a. Static Analysis Testing
b. Dynamic Analysis Testing
c. Penetration Testing
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 230
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 231
Module 8: Analysis & Testing
Quiz – Question 5
Quiz – Question 4
4. To fuzz test an application, an attacker only needs:
Select one:
a. Access to the full source code to the application
b. Access to the application interfaces and runtime (the app itself)
c. Both of the above
d. Neither of the above
5. A Penetration test with negative results, which found no flaws in
the target, means that there really are no flaws in the target?
a. True
b. False
mGovernment 2 3 2
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
Module 1, mGov Training Introduction
2 3 3
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 234
We discuss the strength in learning from others mistakes and failures.
CONTENT
THEMES
• Security, Business Processes & Collaboration.
Module 1, mGov Training Introduction
mGovernment 2 3 5
Module 9: Strength in Failures
Strength in
Failures
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 236
Introduce the Objectives, (read the slide).
CONTENT
This module has these objectives:
1. Understand the strength of learning from others mistakes and failures.
2. Identify some resources for sharing.
Module 9: Strength in Failures
mGovernment 237
• Understand the strength of learning from others mistakes and
failures.
• Identify some resources for sharing
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 238
In the engineering world, when something fails, engineers descend upon the
disaster, investigate and determine the causes.
Then they publish a report of findings so that the mistake is less likely to be
repeated.
CONTENT
1. Introduce the idea of engineers investigating failures and publishing reports
detailing the root causes.
Module 9: Strength in Failures
mGovernment 239
What can we learn from history about technology failures?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 240
CONTENT
Background:
This is the original Tacoma Narrows Bridge. It opened for traffic on 1 July 1940
and collapsed 7 November of the same year. At the time, it was the 3d largest
(longest) suspension bridge in the world, behind the Golden Gate in San Francisco
and the George Washington in NYC.
What you are seeing here is called resonance.
The winds that day struck the resonance point of the bridge, causing it to vibrate
and oscillate, with unforeseen consequences.
The bridge’s collapse had a lasting effect on science and engineering. In many
physics textbooks, the event is presented as an example of elementary forced
resonance with the wind providing an external periodic frequency that matched
the bridge’s natural structural frequency.
Almost every engineering or physics student in the world sees this video at some
point in their education.
1. Reinforce that engineers investigate disasters and report on problems.
Module 9: Strength in Failures
mGovernment 241
Bridge Failures
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 242
This is a video of the Hindenburg disaster. The crash of LZ 129 took place in
Lakehurst, NJ, 6.5.1937
There had been many successful flights up to this point….. but it only takes one
failure.
In this case a combination of events culminated in a static spark which set off
Hydrogen gas which had accumulated between the buoyancy bladders and the
outer skin of the airship.
CONTENT
1. Reinforce that engineers investigate disasters and report on problems.
Module 9: Strength in Failures
mGovernment 243
Aviation Failures
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 244
CONTENT
The point of this module should be obvious now.
Engineers collectively learn from individual failures.
We are in an engineering field as well, and should apply the same mindset, but
there is a great deal of resistance. It’s simply embarrassing if nothing else.
Share information on failures, at least with the aeCERT.
Preferably, share with other members of the same team and with other teams.
Do not make the same mistakes that others have, learn from their failures, and
let others learn from yours.
1. Reinforce the strength of learning from others failures.
Module 9: Strength in Failures
mGovernment 245
CVE
Glossary
• Building collapses, train crashes, etc.
In these cases, experts investigate, determine the root causes, and
share the information to prevent it from recurring.
• This is not common practice with Information Security!
• Nobody wants to announce their failures.
• Not announcing failures = Not announcing fixes.
• If we don’t share information, how can we learn?
• If we don’t learn, how can we improve?
Failure is Everywhere
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 246
CONTENT
SOURCES
We’ve mentioned OWASP and the CVE project as resources in the past.
These are links to the developer web sites for each of the platforms.
Don’t forget Google. We recommend you search periodically for vulnerability
disclosure discussions. These tend to move around for various reasons.
1. Provide a summary of some resources already mentioned, and some others.
• owasp.org• cve.mitre.org• developer.android.com• developer.apple.com• devcenter.windowsphone.com• developer.blackberry.com
Module 9: Strength in Failures
mGovernment 247
• Familiar ones:
• OWASP Top 10 and other of their resources
• CVE: list of vulnerabilities, each typically with a brief description, patch
or fix information, proof of concept code for use in testing, etc.
• Platform Developer’s web sites:
• developer.android.com
• developer.apple.com
• devcenter.windowsphone.com
• developer.blackberry.com
• Don’t forget Google
Search for vulnerability disclosure discussions. These have a tendency to
move around.
Some Resources
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 248
CONTENT
Review the Objectives (re-read the slide).
1. Understand the strength of learning from others mistakes and failures.
2. Identify some resources for sharing.
mGovernment 249
Module 9: Strength in Failures
• Understand the strength of learning from others mistakes and
failures.
• Identify some resources for sharing
Review of Objectives
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 250
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 251
Module 9: Strength in Failures
Quiz – Question 1
1. Engineers, including software and security engineers, can
learn valuable lessons by studying the failures of others.
a. True
b. False
mGovernment 2 5 2
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 2 5 3
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 254
We will begin the discussion of security features of the four featured mobile
platforms, beginning with Android. The Android discussion is the longest and
most detailed, for several reasons.
First and foremost, it is the most open platform. The kernel is linux, which is
open. The architecture, which we will see in detail in two slides, is open. Google
has released the bulk of the Android system as open source, so we have the code
and know the most about it.
The bad news is the attacker has the same access, and as we will show you later,
he has easy access to the source code of your applications as well, with all that
that implies.
Another reason that we focus on Android, beyond the fact that it is the most
prevalent smart phone OS in the UAE, is that we are simply starting the overall
discussion of the platforms with it.
We will expose and discuss security features in the context of the Android
discussion, many of which are also present with the other platforms.
Essentially, the Android discussion is the baseline discussion, and we discuss
differences when we review the other platforms.
CONTENT
THEMES
• Architecture, Applications, Security
Module 1, mGov Training Introduction
mGovernment 2 5 5
Module 10: Android Security
Android Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 256
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Understand the architecture of the Android operating system.
2. Understand how components fit together to build applications.
3. Understand the security model.
Module 10: Android Security
mGovernment 257
Objectives
• Understand the architecture of the Android operating system.
• Understand how components fit together to build applications.
• Understand the security mode.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 258
First, relax…. Most of you will live in the blue zone.
This is fondly known as the lasagna model, because of all of the layers. If you’re
an old Unix person, this should look familiar.
Applications:
1. All applications are written using the Java programming language.
2. Android ships with a set of core applications including an email client, SMS
program, calendar, maps, browser, contacts, and others. All applications are
written using the Java programming language.
Application Framework:
3. By providing an open development platform, Android offers developers the
ability to build extremely rich and innovative applications. Developers are free
to take advantage of the device hardware, access location information, run
background services, set alarms, add notifications to the status bar, and much,
much more.
4. Developers have full access to the same framework APIs used by the core
applications. The application architecture is designed to simplify the reuse of
CONTENT
1. Explore the internal architecture of the Android OS.
2. Reinforce that this is a UNIX platform.
mGovernment 259
Android Architecture
Module 10: Android Security
Source: http://developer.android.com/guide/basics/what-is-android.html
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 260
CONTENT
components; any application can publish its capabilities and any other application
may then make use of those capabilities (subject to security constraints enforced
by the framework). This same mechanism allows components to be replaced by
the user.
5. Underlying all applications is a set of services and systems, including:
a. A rich and extensible set of Views that can be used to build an application,
including lists, grids, text boxes, buttons, and even an embeddable web browser
b. Content Providers that enable applications to access data from other
applications (such as Contacts), or to share their own data
c. A Resource Manager, providing access to non-code resources such as localized
strings, graphics, and layout files
d. A Notification Manager that enables all applications to display custom alerts
in the status bar
e. An Activity Manager that manages the lifecycle of applications and provides a
common navigation backstack
6. For more details and a walkthrough of an application, see the Notepad Tutorial
from the Android developer website.
Libraries:
7. Android includes a set of C/C++ libraries used by various components of
the Android system. These capabilities are exposed to developers through the
Android application framework. Some of the core libraries are listed below:
8. System C library - a BSD-derived implementation of the standard C system
library (libc), tuned for embedded Linux-based devices
9. Media Libraries - based on PacketVideo’s OpenCORE; the libraries support
playback and recording of many popular audio and video formats, as well as
mGovernment 261
Module 10: Android Security
CONTENT
static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
10. Surface Manager - manages access to the display subsystem and seamlessly
composites 2D and 3D graphic layers from multiple applications
11. LibWebCore - a modern web browser engine which powers both the Android
browser and an embeddable web view
12. SGL - the underlying 2D graphics engine
13. 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries
use either hardware 3D acceleration (where available) or the included, highly
optimized 3D software rasterizer
14. FreeType - bitmap and vector font rendering
15. SQLite - a powerful and lightweight relational database engine available to
all applications
Android Runtime:
16. Android includes a set of core libraries that provides most of the functionality
available in the core libraries of the Java programming language.
17. Every Android application runs in its own process, with its own instance of
the Dalvik virtual machine (VM). Dalvik has been written so that a device can run
multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable
(.dex) format which is optimized for minimal memory footprint. The VM is
register-based, and runs classes compiled by a Java language compiler that have
been transformed into the .dex format by the included “dx” tool.
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 262
CONTENT
Linux Kernel:
18. The Dalvik VM relies on the Linux kernel for underlying functionality such as
threading and low-level memory management.
19. Android relies on Linux version 2.6 for core system services such as security,
memory management, process management, network stack, and driver model.
The kernel also acts as an abstraction layer between the hardware and the rest
of the software stack.
20. Finally, the Binder provides for Interprocess Communication. As this is
effectively a choke point, it is the structure within the kernel which enforces the
permissions defined by the application developer in the AndroidManifest.xml file.
More on this in a couple of slides.
mGovernment 263
http://developer.android.com/guide/basics/what-is-android.html
• Dalvik: The Java Virtual Machine inside Android.
SOURCES
Glossary
Module 10: Android Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 264
Activities- For example, an email application might have one activity that shows
a list of new emails, another activity to compose an email, and another activity
for reading emails. Although the activities work together to form a cohesive user
experience in the email application, each one is independent of the others. As
such, a different application can start any one of these activities (if the email
application allows it). For example, a camera application can start the activity in
the email application that composes new mail, in order for the user to share a
picture.
Services- For example, a service might play music in the background while the
user is in a different application, or it might fetch data over the network without
blocking user interaction with an activity. Another component, such as an
activity, can start the service and let it run or bind to it in order to interact with it.
Content Providers: Through the content provider, other applications can query
or even modify the data (if the content provider allows it). For example, the
Android system provides a content provider that manages the user’s contact
information. As such, any application with the proper permissions can query
part of the content provider (such as ContactsContract.Data) to read and write
CONTENT
1. Introduce terms and concepts at the core of Android applications.
Module 10: Android Security
mGovernment 265
• Activities: a single screen with a user interface.
• Services: long-running tasks in background. Services do not expose a UI.
• Content Providers: a shared set of application data: SQLite DB, Web
resource, file system, or other persistent storage.
• Broadcast Receiver: a component that responds to system wide
broadcast announcements.
Application Components “Android vocabulary Lesson”
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 266
CONTENT
information about a particular person. Content providers are also useful for
reading and writing data that is private to your application and not shared. For
example, the Note Pad sample application uses a content provider to save notes.
Broadcast Receiver: Many broadcasts originate from the system—for example,
a broadcast announcing that the screen has turned off, the battery is low, or a
picture was captured. Applications can also initiate broadcasts—for example, to
let other applications know that some data has been downloaded to the device
and is available for them to use. Although broadcast receivers don’t display a
user interface, they may create a status bar notification to alert the user when
a broadcast event occurs. More commonly, though, a broadcast receiver is just
a “gateway” to other components and is intended to do a very minimal amount
of work. For instance, it might initiate a service to perform some work based on
the event.
Module 10: Android Security
mGovernment 267
• Activities: a single screen with a user interface.
• Services: long-running tasks in background. Services do not expose a UI.
• Content Providers: a shared set of application data: SQLite DB, Web
resource, file system, or other persistent storage.
• Broadcast Receiver: a component that responds to system wide
broadcast announcements.
Application Components “Android vocabulary Lesson”
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 268
Using an email application as an example, talk through the terms from the
previous slide and how they would play together to build a complete email
application.
The email application might have three activities or screens, one to read mail,
a second to compose mail, and a third to list messages in a folder. All of these
Activities will be visible to the user.
They will communicate with Services to send and receive mail.
These will communicate with a Content Provider to store the mail, attachments,
etc.
Finally, the application contains a Broadcast Receiver so that it can me notified
of things like low battery, screen shut down, etc.
CONTENT
1. Reinforce the terms and definitions from the previous slide using this
graphic.
Module 10: Android Security
mGovernment 269
Components in Context
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 270
From a high level, these mechanisms are how application components
communicate with each other.
For some students, that may be all of the detail that they need. More advanced
individuals may be interested in the details below:
Intents are asynchronous messages which allow application components to
request functionality from other Android components. Intents allow you to
interact with components from the same applications as well as with components
contributed by other applications. For example, an activity can start an external
activity for taking a picture.
There are separate methods for activating each type of component:
You can start an activity (or give it something new to do) by passing an Intent to
startActivity() or startActivityForResult() (when you want the activity to return a
result).
You can start a service (or give new instructions to an ongoing service) by passing
an Intent to startService(). Or you can bind to the service by passing an Intent to
bindService().
CONTENT
1. Discuss messaging between the various Android application components.
Module 10: Android Security
mGovernment 271
• Intent:
• Asynchronous Message sent to activate a Activity, Service or
Broadcast Receiver.
• Sending an Intent
• Content Resolver:
• Activates Content Provider
Component Messaging
CONTENT
You can initiate a broadcast by passing an Intent to methods like sendBroadcast(),
sendOrderedBroadcast(), or sendStickyBroadcast().
You can perform a query to a content provider by calling query() on a
Content Resolver.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 272
The “this app needs access to $resource” messages the user gets at install time
are driven by this file and its contents.
The AndroidManifest.xml file is created by the application developer.
It contains quite granular controls and permissions, but once it is packaged with
the application components into the .apk file, it becomes an all-or-nothing thing.
In other words, at install-time, the end user is presented with the permission list
in the form “This application will access the following resources <list>”. The end
user has only one choice at that point, install the application with the associated
permissions, or do not install.
The access limits are enforced by? The Binder in the kernel.
Other platforms handle this differently. iOS for example allows the user to adjust
some permissions and access controls post-install.
CONTENT
1. Introduce the AndroidManifest.xml file and its functions.
Module 10: Android Security
mGovernment 273
Metadata about the application is stored in and loaded from
AndroidManifest.xml
Manifest File
• Identify any user permissions the application requires, such
as Internet access or read-access to the user’s contacts.
• Declare the minimum API Level required by the application,
based on which APIs the application uses.
• Declare hardware and software features used or required by
the application, such as a camera, or a multi-touch screen.
• API libraries the application needs to be linked against (other
than the Android framework APIs), such as the Google Maps
library.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 274
As you can see, the Manifest file is written in XML, Extensible Markup Language
Extensive documentation on the Manifest is available on the Android developer
website at the URL on the slide.
Some selected examples:
In the <application> element, the android:icon attribute points to resources for
an icon that identifies the application.
In the <activity> element, the android:name attribute specifies the fully qualified
class name of the Activity subclass and the android:label attributes specifies a
string to use as the user-visible label for the activity.
You must declare all application components this way:
<activity> elements for activities
<service> elements for services
<receiver> elements for broadcast receivers
<provider> elements for content providers
CONTENT
1. Show an example Manifest file.
Module 10: Android Security
mGovernment 275
<?xml version=”1.0” encoding=”utf-8”?>
<manifest ... >
<uses-permission android:name=”android.permission.WRITE_
EXTERNAL_STORAGE” android:maxSdkVersion=”18” />
<application android:icon=”@drawable/app_icon.png” ... >
<activity android:name=”com.example.project.ExampleActivity”
android:label=”@string/example_label” ... >
</activity>
...
</application>
</manifest>
Reference: https://developer.android.com/guide/topics/manifest/
manifest-intro.html
Android Manifest.xml
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 276
XML: Extensible Markup Language.
https://developer.android.com/guide/topics/manifest/manifest-intro.html
Glossary
SOURCES
CONTENT
Activities, services, and content providers that you include in your source but do
not declare in the manifest are not visible to the system and, consequently, can
never run.
However, broadcast receivers can be either declared in the manifest or created
dynamically in code (as BroadcastReceiver objects) and registered with the
system by calling registerReceiver().
Module 10: Android Security
mGovernment 277
<?xml version=”1.0” encoding=”utf-8”?>
<manifest ... >
<uses-permission android:name=”android.permission.WRITE_
EXTERNAL_STORAGE” android:maxSdkVersion=”18” />
<application android:icon=”@drawable/app_icon.png” ... >
<activity android:name=”com.example.project.ExampleActivity”
android:label=”@string/example_label” ... >
</activity>
...
</application>
</manifest>
Reference: https://developer.android.com/guide/topics/manifest/
manifest-intro.html
Android Manifest.xml
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 278
Android is a privilege-separated operating system, in which each application runs
with a distinct system identity (Linux user ID and group ID). Parts of the system
are also separated into distinct identities. Linux thereby isolates applications
from each other and from the system.
Additional finer-grained security features are provided through a “permission”
mechanism.
Permissions are declared by the developer in the AndroidManifest.xm file, and
enforced by the binder component of the underlying linux kernel.
Permissions are enforced:
• At the time of a call into the system, to prevent an application from executing
certain functions.
• When starting an activity, to prevent applications from launching activities of
other applications.
• When both sending and receiving broadcasts, to control who can receive your
broadcast or who can send a broadcast to you.
CONTENT
1. Discuss some details about the permissions declared in the AndroidManifest.
xml file.
Module 10: Android Security
mGovernment 279
Permissions
• Included in AndroidManifest.xml, used to protect data and
functionality
• Permission makes the application boundary, enforced in kernel
• Examples
• Use system:
• android.permission.CALL_EMERGENCY_NUMBERS
• Read data
• android.permission.READ_OWNER_DATA
• Write data
• android.permission.WRITE_CONTACTS
• Set System settings
• android.permission.SET_WALLPAPER
Reference: https://developer.android.com/guide/topics/security/
permissions.html
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 280
CONTENT
• When accessing and operating on a content provider.
• When binding to or starting a service.
ALL enforced within the underlying Linux kernel.
https://developer.android.com/guide/topics/security/permissions.html
SOURCES
Module 10: Android Security
mGovernment 281
• Included in AndroidManifest.xml, used to protect data and
functionality
• Permission makes the application boundary, enforced in kernel
• Examples
• Use system:
• android.permission.CALL_EMERGENCY_NUMBERS
• Read data
• android.permission.READ_OWNER_DATA
• Write data
• android.permission.WRITE_CONTACTS
• Set System settings
• android.permission.SET_WALLPAPER
Reference: https://developer.android.com/guide/topics/security/
permissions.html
Permissions
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 282
CONTENT
These are some examples of permissions that should be familiar to most Android
users.
The full list of available permissions is on the Android developer website at the
URL on the slide.
1. Provide some examples of some specific permissions.
http://developer.android.com/reference/android/Manifest.permission.html
SOURCES
Module 10: Android Security
mGovernment 283
• ACCESS_COARSE_LOCATION
• Allows an app to access approximate location derived from network
location sources such as cell towers and Wi-Fi.
• ACCESS_FINE_LOCATION
• Allows an app to access precise location from location sources such
as GPS, cell towers, and Wi-Fi.
• NFC
• Allows applications to perform I/O operations over NFC.
• WRITE_EXTERNAL_STORAGE
• Allows an application to write to external storage.
• WRITE_SMS
• Allows an application to write SMS messages.
• Full list at:
http://developer.android.com/reference/android/Manifest.permission.
html
Permission Examples
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 284
Content providers are handled a little differently. Here are some examples.
The details for Content providers are on the Android developers website
beginning at the URL provided on the next slide.
CONTENT
1. Introduce Content Provider Grants.
Module 10: Android Security
mGovernment 285
https://developer.android.com/guide/topics/providers/content-provider-
basics.html
SOURCES
• Different model than permissions.
• Used with Content Providers.
• URI Permissions are a special case.
• URI examples:
• content://com.example.app.provider/AccountsTable.
• A content authority called com.example.app.provider.
• A table called AccountsTable.
• content://com.example.app.provider/AccountsTable/Users.
• A table called Users.
Content Provider Grants
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 286
CONTENT
Grants provide a capabilities model for permissions, for example the ability to
open a file attachment.
They are applied or enforced at the Intent filter, which is declared in the
AndroidManifest.xml file.
Content providers documentation is on the Android developers website
beginning at the URL provided. Expect to start reading at this page and to follow
links to several others.
1. Continue with examples of Content Provider grants and provide the
reference URL.
Module 10: Android Security
mGovernment 287
• Grants - Implement a capabilities model for Granting permissions,
such as opening up a file attachment
• Applied at the Intent filter
• Can be used for granular, event based access
• Read permission:
• FLAG_GRANT_READ_URI_PERMISSION
• Write permission:
• FLAG_GRANT_WRITE_URI_PERMISSION
• Reference:
https://developer.android.com/guide/topics/providers/content-
provider-basics.html
Content Provider Grants (2)
SOURCES
https://developer.android.com/guide/topics/providers/content-provider-
basics.html
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 288
If you remember, this is the graphic we used when we introduced the terms
Activity, Service, Content Provider and Broadcast Receiver, to illustrate how the
components fit together to make up an app.
At this point, we have overlaid it with the security mechanisms we’ve been
discussing so you can see how it all fits together.
All of these controls, to reiterate, are declared by the developer in the
AndroidManifest.xml file, and enforced by the underlying linux kernel.
The permissions are reported to the user at install-time, where the user must
accept them as declared, or decline to install the app.
CONTENT
1. Bring the security controls together with the application components.
Module 10: Android Security
mGovernment 289
Glossary
SDLC: Software Development Life Cycle.
Using Permissions
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 290
Here is a checklist to follow prior to deployment of a application.
Share this with the development team at the beginning of the SDLC so that there
are no surprises at the end.
The conversation with the development staff should be something along the
lines of:
“Here are the things I as the security person am concerned that we get right.
Understand that I will be reviewing all of this with you prior to approving the
application.”
CONTENT
1. Provide a checklist for reviewing permissions with the development staff.
Module 10: Android Security
mGovernment 291
Pre-Deployment Checklist
• Review Android Manifest.
• Inspect permissions for:
• Activities
• Services
• Intents & Intent filters
• Content providers
• Broadcasts
• Custom permissions
• Grants
Permission Review
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 292
Review the Objectives (re-read the slide).
CONTENT
1. Understand the architecture of the Android operating system.
2. Understand how components fit together to build applications.
3. Understand the security model.
mGovernment 293
Module 10: Android Security
• Understand the architecture of the Android operating system.
• Understand how components fit together to build applications.
• Understand the security model.
Review of Objectives
It is now time to review your knowledge
of this material
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 294
Quiz – Question 1
1. The Binder is the structure within the kernel that enforces
the permissions defined by the application developer in the
AndroidManifest.xml file.
a. True
b. False
Module 1, mGov Training Introduction
mGovernment 295
Module 10 : Android Security
Quiz – Question 3
Quiz – Question 2
3. An Android Intent is used to access Content Providers?
a. True
b. False
2. Android Content Providers are used to?
Select one:
a. Send and Receive SMS messages
b. Access Web content via URIs
c. Store and manage data
d. Both B and C
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 296
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 297
Module 10: Android Security
Quiz – Question 5
Quiz – Question 4
4. In designing Android apps it is best to allow the maximum
level of permissions to all the phones features and services:
Select one:
a. True
b. False
5. On the Android platform, resources which the app can access
are declared:
Select one:
a. In the AndroidManifest.xml file.
b. When uploading the app to the Google Play store.
c. By the CA when Signing the app.
d. In the Source Code.
mGovernment 2 9 8
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
Module 1, mGov Training Introduction
mGovernment 2 9 9
mGovernment 300
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
We will continue our discussion of security on the android platform, now focusing
on securing the app.
CONTENT
THEMES
• Architecture, Applications, Security.
• Accessed through the web browser
• Deployed over Internet
• Can develop/design one application for all platforms
• A cross-platform mobile application
• Provides uniformity across all platforms
• Near-instant updates
• Updates to the application are actually updates to the website,
happening on the back-end
Introduction
SDLC: Service Delivery Lifecycle
Glossary
mGovernment 301
Module 11: Defending Android Apps
DefendingAndroid Apps
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 302
Introduce the Objectives, (read the slide).
CONTENT
This module has these objectives:
1. Understand the security features of the Android OS.
2. Discuss data encryption and key management.
3. Understand the code signing process.
Module 11: Defending Android Apps
mGovernment 303
• Understand the security features of the Android OS.
• Discuss data encryption and key management.
• Understand the code signing process.
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 304
We will discuss each of these topics in this module.
Note that many of these topics are relevant in one form or another on other
platforms.
CONTENT
1. Outline the topics covered in this module.
Module 11: Defending Android Apps
mGovernment 305
• Building A Sandbox.
• Data Encryption.
• Key Management.
• ASLR (Address Space Layout Randomization).
• Secure Element.
• Input Validation.
• Code Signing Process.
Defending Android Apps
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 306
A sandbox is a limited execution environment.
The term comes from sandboxes that children play in, and it’s a good metaphor:
• It’s a safe environment, with soft sand, and safe toys
• It has a boundary, to keep the kids in, threats out, and to limit interaction in-
and-out
The sandbox begins and ends with the linux kernel.
At the beginning, each application runs with a unique UNIX UID and GID (User
ID and Group ID), and the associated UNIX file permission model that goes with
it. Each file has access rights of Read, Write, Execute (or a combination thereof)
associated with it on a per-User, per-Group and Other basis. We get basic access
controls or permissions based on this.
Finer grained permissions are specified in the Manifest as we discussed previously.
This means, as we mentioned previously, that the permission declarations in the
AndroidManifest.xml file MUST be set up correctly, to allow the minimum access
necessary for the app to perform its task, and that the security professional
MUST review that manifest carefully.
CONTENT
1. Understand the “sandbox” and how it is built and configured on the Android
platform.
Module 11: Defending Android Apps
mGovernment 307
Building a sandbox
• Signed apk creates isolation boundary for application & its data
• Reviewing manifest & permissions required
• Kernel enforces sandbox protections
• An application should execute only within its own sandbox, and not
rely on other applications to boot or execute code
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 308
CONTENT
Developers should be prepared to defend and justify every permission they
grant, and the security prodessional should challenge every one.
It is possible to allow applications to “cross the boundary” of the sandbox, i.e., to
access resources outside the sandbox. In general, this is bad practice.
To summarize, each app or .apk runs within its own sandbox as we have described.
We strictly limit what can cross the boundaries of the box with the permissions of
the AndroidManifest.xml file.
And, at the end, it’s all enforced by the binder in the underlying Linux kernel.
Module 11: Defending Android Apps
mGovernment 309
Building a sandbox
• Signed apk creates isolation boundary for application & its data
• Reviewing manifest & permissions required
• Kernel enforces sandbox protections
• An application should execute only within its own sandbox, and not
rely on other applications to boot or execute code
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 310
Mobile devices with the sensitive data they usually contain and process present
a challenging problem: how do we secure that data when the device is likely to
be stolen, and the data flows over untrusted networks from the device to the
servers in the back end?
We address this largely through encryption. Data at Rest (DAR) and Data in Transit
(DIT) MUST therefore be encrypted.
The problem with a sentence like “DAR and DIT must be protected by encryption”
is that is in the passive voice. It tells you what has to happen, but not who has
to do it.
The developer MUST code the application to encrypt data where necessary, and
to communicate through SSL / TLS, and MUST do this correctly.
The Security processional MUST audit to ensure that this was done, and works
properly.
Key management is always a challenge; see the next slide.
CONTENT
1. Understand Android cryptography resources.
Module 11: Defending Android Apps
mGovernment 311
Glossary
DAR: Data at Rest.
DIT: Data in Transit.
• DAR and DIT must be protected by encryption
• DAR requires file encryption, DIT requires SSL / TLS
• Must be programed in; it is NOT automatic or done by the OS
• The Android Crypto Libraries
recommended include:
• javax.crypto
• javax.crypto.interfaces
• java.security
• java.security.cert
Data encryption
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 312
This is one of those weak points where developers consistently make mistakes
that compromise the integrity of the system.
If you are storing the key somehow, unprotected, on the same device as the
encrypted storage, you might as well have never encrypted it.
Get professional help here, and follow well-established guidelines / procedures,
i.e. PKCS from RSA. PKCSs are now maintained by the IETF in several RFCs.
Specifically, PBKDF2 from PKCS5, RFC 2898 can help with the key management
problem.
CONTENT
1. Discuss Key Management.
PKCS: Public Key Cryptography Standards, originally from RSA, now in various
RFCs from the IETF.
PBKDF2: Password-Based Key Derivation Function 2.
RSA: RSA.com, a security company, now a part of EMC.
RFC: Request for Comment, a standards or informational document from the
IETF.
IETF: Internet Engineering Task Force, the standards body for the Internet.
Glossary
Module 11: Defending Android Apps
mGovernment 313
• Why is it important?
Kerckhoff’s principle from 1883 states that the strength of a
cryptosystem depends on the key not the algorithm
• This is the hardest problem in cryptosystems!
• Not a technical problem - a systems engineering problem
• The process of:
• Key creation - generating keys for use in the system,
• Key distribution - exchanging keys
• Key protection - placing security mechanism to guard the keys
• Key storage - persisting the key, e.g. in a directory
• Key validation - is this a valid request
• Lifecycle management - revoking and
Key management
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 314
Normally, when a program is loaded, it is laid out into memory the same way
each time. In other words, a particular program instruction or piece of data will
always have the same address.
Attackers exploit this condition by overflowing an input buffer with their malicious
payload. They adjust the target location for the payload with an offset, and
having the program addresses always the same makes it easy for the attacker to
put HIS code where HE wants it.
Programmers should write code to validate all input, including truncating the
data input to the size of the buffer allocated to receive it.
Programmers are not perfect, and for various reasons, do not always do this.
ASLR randomizes the addressing, so that a given program does not load into
memory exactly the same way twice. Since specific instructions or data are no
longer in predictable locations, it is much more difficult for the attacker to put
HIS code where HE wants it.
This protection is NOT perfect, and should be considered the SECOND line of
defense. The first is good code.
CONTENT
1. Introduce Address Space Layout Randomization.
Module 11: Defending Android Apps
mGovernment 315
ASLR: Address Space Layout Randomization.
Glossary
• Provides some buffer
overflow protection
• Not perfect, but making
steady progress
• In Android since 4.0, 4.1
ASLR
Reference: https://en.wikipedia.org/wiki/Address_space_layout_randomization
https://en.wikipedia.org/wiki/Address_space_layout_randomization
SOURCES
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 316
The secure element provides secure storage of credentials (digital certificates).
This is done in dedicated, segregated hardware managed by a dedicated secure
OS separate from the host OS. A secure element is currently present in many
handsets, including several Android devices.
In the context of smart cards, an application protocol data unit (APDU) is the
communication unit between a smart card reader and a smart card. In this
context, the firewall rules managing the APDUs would be between the Secure
Element with its dedicated OS, and the host OS.
Certificates are loaded into the secure element and managed by an entity called
the TSM, Trusted Service Manager. This hierarchy as depicted in the graphic will
let, for example, Emirates ID securely load your EIDA digital certificate into the
secure element in your phone, using the wireless carriers (du and Etisalat) as the
proxies, thus facilitating identity operations.
If the handset also has an NFC radio, and app can retrieve the credential from the
secure element and present it for identity, or perhaps payment, via NFC.
The FedNet project in the UAE will include a national TSM and integration with
CONTENT
1. Introduce the Secure Element.
2. Introduce the TSM.
Module 11: Defending Android Apps
mGovernment 317
CONTENT
EIDA and other entities.
Interestingly, Secure Elements are not present in iOS devices, although there
are third party devices to add them. These usually consist of a sleeve with an
integrated NFC radio, and an SD card slot. The actual secure element is typically
implemented in the SD Card.
• Option for higher assurance Key
storage
• Runs in a logically and physically
separate OS
• Separate OS means for example
running JavaCard not Android
• Implements firewall rules to restrict
APDU (Application Protocol Data
Unit) access & interfaces
• Communicates with TSM (Trusted
Service Manager) over proxy or
direct means
Secure Element
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 318
Input validation is not Android specific, nor is it security specific, it’s just solid
coding practice.
The idea is simple: keep garbage out of the system by only accepting valid input.
Whole classes of attacks are thwarted by this simple practice.
In general, we can perform this one of two ways known as “whitelisting” and
“blacklisting”.
With whitelisting, we filter the input and only allow known good data through.
With blacklisting, we filter the input, and block known bad data.
We talk about this during the Analysis & Testing module, but we can test for
improper input validation with several techniques, not the least of which is
“fuzzing”
CONTENT
1. Discuss the importance of input validation.
Module 11: Defending Android Apps
mGovernment 319
• Required to protect against malicious
injection of SQL, JavaScript and other
commands
• Approaches include –
• whitelist validation: default deny,
accept only known good
• blacklist validation: default allow,
block known bad input
Input Validation
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 320
These are the mechanics of how to final-package and sign an Android application.
Note this is a command line example, some IDEs will do most, if not all of this for
you if configured (ex: Appcelerator)
The Android system requires that all installed applications be digitally signed with
a certificate whose private key is held by the application’s developer. The Android
system uses the certificate as a means of identifying the author of an application
and establishing trust relationships between applications. The certificate is not
used to control which applications the user can install.
The certificate does not need to be signed by a certificate authority: it is perfectly
allowable, and typical, for Android applications to use self-signed certificates.
This is a significant weakness of the Android system of code signing as compared
with the code signing procedures in place for the other major mobile platforms.
CONTENT
1. Describe the code signing process for Android Apps.
Module 11: Defending Android Apps
mGovernment 321
Glossary
• Get a private key for signing (either from CA like VeriSign or gener-
ate your own from OpenSSL)
• Compile application in release mode (example ant release)
• Sign application with private key
• $ jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore
my-release-key.keystore my_application.apk alias_name
• Run zipalign (in Android SDK) performance optimization, reduces
RAM usage
Code Signing Process
IDE: Integrated Development Environment.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 322
There is a Good news, Bad news scenario here.
The Good news is that Google and Android require code to be signed, and we get
some security benefits from that.
The Bad news is that Google goes not require a certificate from a specific trusted
third party, i.e. they allow self-signed certificates, so we as end users have no real
assurance as to the identity of the author of an application like we do on the
other platforms.
CONTENT
1. Continue code signing discussion.
Module 11: Defending Android Apps
mGovernment 323
• All Android applications must be signed.
• Signature makes isolation boundary for application.
• Google / Android team currently requires No Central CA, self
sign is supported.
• Sign apk with private key with Keytool, jarsigner or other tool.
• Required to publish to App Market.
Code Signing Notes
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 324
Review the Objectives (re-read the slide).
CONTENT
1. Understand the security features of the Android OS.
2. Discuss data encryption and key management.
3. Understand the code signing process.
mGovernment 325
Module 11: Defending Android Apps
• Understand the security features of the Android OS.
• Discuss data encryption and key management.
• Understand the code signing process.
Review of Objectives
It is now time to review your knowledge
of this material
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 326
Quiz – Question 1
1. The PBKDF2 function is used for:
Select one:
a. Authenticating access to an application’s data.
b. Playing Angry Birds.
c. Keeping information confidential, protecting storage.
d. None of the Above.
e. Both A & C.
Module 1, mGov Training Introduction
mGovernment 327
Module 11 : Defending Android Apps
Quiz – Question 2
Quiz – Question 3
3. The Secure Element:Select one:
Select one:
a. Is not present on iOS platforms prior to iPhone 6
b. Was a Science Fiction film starring Bruce Willis
c. Runs the same OS as the platform OS
d. Is implemented inside the Android Kernel
2. Address Space Layout Randomization (ASLR) defends against
buffer overflow attacks?
Select one:
a. True
b. False
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 328
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 329
Module 11: Defending Android Apps
Quiz – Question 4
Quiz – Question 5
4. A Secure Element can best be used:
Select one:
a. To authenticate using the public-key cryptography as with
smart card use
b. To integrate with an NFC chip providing for secure micro-
payments
c. As a separate secure data storage device like an SD card for
your pictures
d. A and B
5. Applications for the Android platform must be signed a
certificate issued by Google:
Select one:
a. True
b. False
mGovernment 3 3 0
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 3 3 1
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 332
THEMES
CONTENT
• Applications, Security
In this module, we will show you how simple it is for an attacker to decompile
your Android app and gain access to your source code.
mGovernment 333
Module 12: Decompiling Android Apps
Decompiling Android Apps
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 334
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Understand the ease with which an attacker can decompile your app and
gain access to your source code.
2. Understand the implications:
a. Ability to Trojan apps.
b. Ability to reverse engineer the back end APIs.
Module 12: Decompiling Android Apps
mGovernment 335
• Understand the ease with which an attacker can decompile your
app and gain access to your source code.
• Understand the implications:
• Ability to Trojan apps.
• Ability to reverse engineer the back end APIs.
Objectives
LEARNING OBJECTIVES
INSTRUCTOR GUIDANCE
CONTENT
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 336
• Situational Awareness: This is shared across several mobile platforms.
We will talk through the process of building an Android app at a high level, and
de-compiling it like an attacker to get back to the source code.
Let’s begin with Building the app
We start with Java source code in plain text
First we compile it into java class files
Then we run through several packaging steps
If you have an IDE (Integrated Development Environment), it will probably do
a lot of this for you automatically
Now, let’s reverse the process
We go through several steps to un-package and get back to first a dex file,
then a jar file, and finally to class files
Then we de-compile the class files and end up
Back where we started, with plain text source code
1. Overview the build process.
2. Overview the de-compilation process.
Module 12: Decompiling Android Apps
mGovernment 337
Reverse Engineering apk
Package it Build the app:
Un-Package it De-Compile itIn Reverse:
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 338
CONTENT
The next 18 slides are screenshots from the hands-on activity of decompiling
an Android Application.
They assume that the student has a notebook prepared with the tools nec-
essary.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 339
• Hands-on, decompiling from the Windows Platform.
Demonstration
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 340
CONTENT
Beginning from the Windows desktop, open the highlighted folder in the low-
er left, labeled “Decompiler Lab”.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 341
Open Decompiler Lab
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 342
CONTENT
Each folder contains two or more files, including an Instructions.txt file. For all
of the steps, the process for the student is to open the Instructions file, read
and follow the directions.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 343
Open Step1-APK
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 344
CONTENT
Each folder contains two or more files, including an Instructions.txt file. For all
of the steps, the process for the student is to open the Instructions file, read
and follow the directions.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 345
Find mGov.apk
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 346
CONTENT
For step One, rename the .apk file, i.e. the Android Application to end with .zip.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 347
Rename to mGov.zip
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 348
CONTENT
The windows OS will pop up a warning like this one, indicating that changing
the file extension might break some things. Don’t worry, that’s exactly what
we want to do.
Windows uses the filename extension to know what type of file it is, and how
the operating system should handle it.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 349
Click Yes
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 350
CONTENT
Notice that once the file is renamed, the icon for the file changes to that of a
compressed folder.
Double click on the file icon to open the compressed folder, i.e. the zip file.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 351
Double-click mGov.zip
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 352
CONTENT
Opening the .zip file reveals the contents, specifically the structure of the
packaged Android Application. Notice the AndroidManifest.xml file, which
defines the permission and access controls for the application. The developer
prepared this.
Exploring the res folder will eventually reveal graphics files.
Viewing them and comparing them to the running Android Application will
show that these files contain the graphical resources used to build elements
displayed on the screen.
Finally, notice the classes.dex file, which is the actual Dalvik executable run by
the Android system. This contains the compiled application code, and we will
work with it in Step 2.
Navigate to the higher folder.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 353
Browse the different files
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 354
CONTENT
Now, navigate to the Step 2 folder….
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 355
Open Step2-dex2jar
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 356
CONTENT
Open and follow the instructions in the Instructions file:
Double click on the shortcut to the command prompt. It’s important to
use the provided shortcut, as it opens the command prompt window in the
correct directory, and with the command execution prompt set properly to
allow the student access to the necessary commands.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 357
Double-click Command Prompt
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 358
CONTENT
The command prompt window should look like this.
Confirm that you are in the proper folder by looking at the path in the prompt.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 359
Command Prompt opens
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 360
CONTENT
Type in the command as shown and hit enter to execute it.
The command is: d2j-dex2jar.bat mGov.apk.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 361
Enter this command:
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 362
CONTENT
The command just executed converts the Dalvik executable (the .dex file) into
a normal Java executable (the .jar file).
When finished, navigate to the higher folder.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 363
The program runs
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 364
CONTENT
Now, navigate to the Step 3 folder.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 365
Open Step3-JD-GUI
mGov Application Developers Course -Day 3
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 366
CONTENT
Open and follow the directions in the Instructions file:
Double click on the jd-gui.exe file. This will open a Java Decompiler with a
Graphical User Interface.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 367
Double-click jd-gui.exe
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 368
CONTENT
The Decompiler should look like this..
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 369
Java Decompiler opens
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 370
CONTENT
Drag the .jar file produced in step 2 and drop it in the running decompiler
window.
Alternatively, use the File menu in the decompiler menu bar to open the .jar
file.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 371
Drag/drop mGov-dex2jar.jar into Java Decompiler
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 372
CONTENT
A folder hierarchy should appear on the left side of the decompiler.
Single click on the plus sign to the left of the folders to open them and explore.
Continue to open sub-folders until you see files with a “J” icon.
These are the actual java class files, which are the compiled versions of the
java components of the application.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 373
Folders appear on the left
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 374
CONTENT
Clicking on any of the class files (the “J” icons) will cause the source code to
appear in the right panel.
Notice that the formatting (tabs, indents and spaces) and comments appear
as they were entered by the original developer.
It is really that simple to decompile an Android application, and to access the
source code and the developers comments.
1. Walk the students through the decompilation process.
Module 12: Decompiling Android Apps
mGovernment 375
Expand the folders to review the application code
mGov Application Developers Course -Day 3
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 376
CONTENT
All of these controls are good, but with the following combination of problems:
• An attacker can de-compile your (or any other) application and get to the
source code
• An attacker can insert his own code, and recompile / repackage it with his
own matching AndroidManifest.xml
• Since Google will accept any certificate to perform the app signing, he can
re-sign his now trojaned version of your app
• The user can be tricked into accepting and loading this app, and if the
“Unknown Sources: Allow installation of apps from sources other than the
Play Store” box is checked under Security in Settings, the app will load and run
The Android security model, which is otherwise quite robust, can be completely
circumvented by this.
Users must understand to never load apps from untrusted sources, and to not
check the box to allow that.
Developers, and that means mGov developers, should NEVER release apps
through other than the official store channel.
1. Understand the implications of being able to easily de-compile Android
apps.
Module 12: Decompiling Android Apps
mGovernment 377
CONTENT
Primary components
• All Applications must be signed by
the developer
• The Android package (.apk) is as-
signed a distinct Linux user ID
• Privileges enforced by Kernel us-
ing Linux user ID and group Id
• Permissions defined in Android-
Mainfest.xml
• Special capabilities based permis-
sions for URI access of Content
Providers
Security Architecture
In addition, this ability to de-compile means that the attacker can reverse
engineer the API for your back end, plus he has running example code in the form
of the original app itself. This gives the attacker a huge head start on attacking
your back end.
And remember, a trojaned app usually compromises one user at a time. Attacking
the back end can yield ALL of the data it contains.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 378
CONTENT
Here is an example of a trojaned, or fake application in the wild.
Droid 09 masqueraded as banking application, but it was not.
It targeted several large banks, some, like First Tech Credit Union did not even
have a REAL banking application available, nontheless, users downloaded and
installed the app.
If you do not yet have a mobile app, you might want to make it apparent on
your traditional web site that you do not.
If you do have an app, make it clear that it is only available through the official
app store, and provide links.
1. Expose a real trojaned application.
Module 12: Decompiling Android Apps
mGovernment 379
• Masquerades as banking application
• Targeted many different medium to large sized
banks – Chase, Sun Trust, BB&T, and others
• First Tech Credit Union posted a warning on
its site about the issue, saying
“If you did download the Droid09 app, please remove it from your phone and take it to
your mobile provider to ensure it’s completely removed”. It adds, “As a reminder, we
don’t currently have an app for the Android phone.”
• Reference: http://www.theinquirer.net/inquirer/news/1585716/
fraud-hits-android-apps-market
Droid 09
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 380
CONTENT
Review the Objectives (re-read the slide).
1. Understand the ease with which an attacker can decompile your app and
gain access to your source code
2. Understand the implications:
a. Ability to Trojan apps
b. Ability to reverse engineer the back end APIs
Module 12: Decompiling Android Apps
mGovernment 381
• Understand the ease with which an attacker can decompile your
app and gain access to your source code.
• Understand the implications:
• Ability to Trojan apps.
• Ability to reverse engineer the back end APIs.
Review of Objectives
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 382
It is now time to review your knowledge of this material
mGovernment 383
Quiz – Question 1
Module 12: Decompiling Android Apps
1. Decompilation of Android apps:
Select all that are correct:
a. Reveals the source code
b. Exposes the API for the back end
c. Facilitates building trojaned versions of the original app
d. Is so hard and time consuming that it is not a threat
mGovernment 3 8 4
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 385
LEARNING OBJECTIVES
mGovernment 386
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
CONTENT
Code obfuscation techniques make it more difficult for an attacker to easily
decompile apps to readable source code.
Obfuscation: hiding of meaning, making code confusing, ambiguous, and
harder to interpret.
• Applications, Security.
Glossary
mGovernment 387
Module 13: Code Obfuscation
Code Obfuscation
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 388
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Expose Obfuscation.
2. Explain the limits of obfuscation techniques.
Module 13: Code Obfuscation
mGovernment 389
• Expose Obfuscation
• Understand the limits of obfuscation techniques
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 390
Access to source code and reverse engineering applications is ALWAYS an issue
from a security point of view.
All that really means is that the obscurity layer of the security is gone.
As the de-compilation example makes clear, the attacker will be able to read your
source code. He will find anything you have tried to “secure” by hiding it in the
code. While he will not see the source for your back end through this process, he
will see how the front end (the mobile application) communicates with the back
end, so at least that portion of your API will be exposed, with running example
code!
We cannot prevent this, but we can make it more difficult.
CONTENT
1. Overview the build process.
2. Overview the de-compilation process.
Module 13: Code Obfuscation
mGovernment 391
• Native apps introduce client-side code which, as HTML5 apps,
would be server-side, therefore hidden
• Attackers can find vulnerabilities through source code analysis
• Attackers can learn how the backend works by reviewing the native
app code
Is Decompilation of Applications an Issue?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 392
CONTENT
A lot of security, be it physical or information security, is about making things
more difficult or time consuming for the attacker. If we as the defenders can
make the target more difficult to attack, then perhaps we can deter the attacker,
or redirect him to a less well-defended target.
That is specifically what obfuscation does; it makes it more difficult (but not
impossible) to read the code.
We hope that the attacker, when faced with obfuscated code, will choose another
target.
1. Define and explain obfuscation.
Module 13: Code Obfuscation
mGovernment 393
• A technique which rewrites the code into a style that is more
difficult to analyze and understand
• Code Obfuscation creates a situation where an attacker must
spend more time, money, and resources to study the code
Code Obfuscation
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 394
CONTENT
This is a simple block of JavaScript. It’s not Java like used in Android apps, but
it’s related and close enough to serve as a simple example of some of the
obfuscation techniques.
Let’s step through this block of code. Observe:
• It declares the variable error_level, and sets it to the value 4.
• The two comment styles, and the comments
• The function declarations, and how one function calls the other
• The first function has two arguements, and calls the second function
• The second function has three arguements, but writes some specific text,
and uses some system calls
• Language features like the reserved words, parentheses, brackets,
semicolons, etc., which cannot change
• Style elements like carriage returns, hanging indents, coding conventions
which make it easier for the human to read
1. Explain the basics of a simple block of code.
Module 13: Code Obfuscation
mGovernment 395
Standard JavaScript
var error_level = 4; /* error level to show alerts for*/function log_error(whereStr, msg){
log_common(3,"error:" + whereStr, msg);//call common function
}
function log_common(lvl, whereStr, msg){var buf = '<div class=logitem>' + new Date() +
whereStr + msg + '</div>';if (lvl >= error_level)
alert(buf);errlog.write(buf);
}
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 396
CONTENT
This is functionally the same code block as on the previous slide, except that it
has been “minified” as described in the slide.
Note the reserved words (var function, etc), the numbers of arguments in the
functions, the fixes strings, and the system calls.
Compare with the previous slide and you will see that these two blocks of code
do exactly the same thing.
The machine can not tell the difference, will execute both, and produce the
same result.
The last statement is not strictly 100% accurate. Minification is commonly used
with Javascript to speed up execution. It contains less characters, so it will travel
from the server to the client (in this case a browser) more quickly, and when
received, it will parse and therefor execute more quickly for the same reason.
1. Show and explain a trivial example of obfuscation.
Module 13: Code Obfuscation
mGovernment 397
SOURCES
var q=4;function y(a,b){x(3,”error:”+a,b);}function x(c,d,e){var f=’<div
class=logitem>’+new Date()+d+e+’</div>’;if(c>=q)alert(f);r.write(f);}
• Comments removed
• Unnecessary white-space removed
• Variables changed to shorter names
Reference: https://en.wikipedia.org/wiki/Minification_%28program-
ming%29
Minified JavaScript
https://en.wikipedia.org/wiki/Minification_%28programming%29
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 398
CONTENT
There are more powerful techniques which can be use to obfuscate code.
You have seen the simple level in the previous two slides.
Dead code injection involves inserting code blocks which are never called, or
which perform null operations.
Expressions and hex escapes which are easily parsed by the machine can be
extremely confusing to a human.
We’ll look at the more complex expression substitutions in the next example.
Remember, and we will reinforce this in the next two slides, we are not making it
impossible for the attacker to transform the code back into something human
readable, we are just making it more difficult and time consuming.
1. Expose additional obfuscation techniques.
Module 13: Code Obfuscation
mGovernment 399
• Obfuscation potency, the level confusion to the reader:
• Simple – Minification (Removing code comments & white space,
changing variable names)
• Moderate – Dead code injection
• Complex – Expressions, Hex escapes, etc.
• Obfuscation Resiliency
How difficult it is to put the code back together?
• Remember mobile devices have limited resources and obfuscation
can create performance delays
Not all Obfuscation is the Same
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 400
CONTENT
This is the same source block we started out with before.
Focus on the reserved words, and on the declaration of the variable error_level,
and setting it to 4.
Module 13: Code Obfuscation
mGovernment 401
Standard JavaScript
var error_level = 4; /* error level to show alerts for*/function log_error(whereStr, msg){
log_common(3,"error:" + whereStr, msg);//call common function
}
function log_common(lvl, whereStr, msg){var buf = '<div class=logitem>' + new Date() +
whereStr + msg + '</div>';if (lvl >= error_level)
alert(buf);errlog.write(buf);
}
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 402
CONTENT
This is still readable, but much harder to understand.
Focusing on the reserved words in the language, we can see a variable declaration
in the first line (in red).
Instead of a readable variable name, or a single letter variable name, we now
have “zfafb4b3d80”. This could just as easily be MUCH longer.
The open and close parenthesis in that expression mean in this case “do some
math”
The math is: take the values “0x550” and add to it “1066”, then subtract “0x976)
0x550 and 0x976 are encoded in hexidecimal, 1066 in decimal. The machine
will convert:
0x550 1360
+1066
---------
2426
0x976 - 2422
---------
4
1. Demonstrate more advanced obfuscation techniques.
Module 13: Code Obfuscation
mGovernment 403
Very Obfuscated
var zfafb4b3d80=(0x550+1066-0x976);function
z9fe5826ce8(z0bf8c0e6c8,z26241da7c7){za56048cb23((0x1cf+6841-
0x1c85),”\x65\x72\x72\x6f\x72\x3a”+z0bf8c0e6c8,z26241da7c7);}
function za56048cb23(z26241da7c7,z3309f8f2aa,z2e4d4a9bbf)
{var z0bf8c0e6c8=”\x3c\x64\x69\x76\x20\x63\x6c\x61\
x73\x73\x3d\x6c\x6f\x67\x69\x74\x65\x6d\x3e”+new
Date()+z3309f8f2aa+z2e4d4a9bbf+”\x3c\x2f\x64\x69\x76\
x3e”;if(z26241da7c7>=zfafb4b3d80){alert(z0bf8c0e6c8);}z9df02a65fb.
write(z0bf8c0e6c8);}
CONTENT
We can see with this first line that we are looking at functionally identical code.
Look deeper into the obfuscated code block and you will see additional reserved
words (function), and syntax elements.
This is much harder, but still not impossible to read.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 404
CONTENT
Strongly consider obfuscating your code, particularly if it is a sensitive application.
Tools are out there; google is your friend in locating them.
The CoDI will test your code to determine if you have obfuscated the source, and
recommends that you do.
1. Discuss obfuscation tools.
Module 13: Code Obfuscation
mGovernment 405
Obfuscation Tools
• Automated tools to obfuscate code are available
• Commercial
• Free / Open
• Google will help you find them
• CoDI will test to see if you have obfuscated your source
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 406
CONTENT
Review the Objectives (re-read the slide).
1. Expose Obfuscation.
2. Understand the limits of obfuscation techniques.
mGovernment 407
Module 13: Code Obfuscation
Review of Objectives
• Expose Obfuscation.
• Understand the limits of obfuscation techniques.
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 408
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 409
Module 13: Code Obfuscation
Quiz – Question 1
1. Obfuscation makes it more difficult and time consuming, but
not impossible, for an attacker to read and understand source
code.
Select one:
a. True
b. False
mGovernment 4 1 0
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 4 1 1
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 412
CONTENT
This is a discussion of Public Key Cryptography and PKI.
This is not in any way exclusive to peculiar to Android, but we need understand it
for all platforms and the bigger picture.
THEMES
Glossary
• Applications, Security.
Crypto: Cryptography.
PKI: Public Key Infrastructure.
Module 1, mGov Training Introduction
mGovernment 4 1 3
Module 14: Crypto & PKI
Crypto &
PKI
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 414
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Understand basic cryptography.
2. Understand the difference between symmetric and asymmetric encryption.
3. Understand the fundamentals of a PKI.
Module 14: Crypto & PKI
mGovernment 415
• Understand basic cryptography.
• Understand the difference between symmetric and asymmetric
encryption.
• Understand the fundamentals of a PKI.
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 416
CONTENT
Let’s begin by defining some very basic terms for use in this and some
subsequent modules.
1. Define some basic terms.
Module 14: Crypto & PKI
mGovernment 417
• Encryption: Turns a clear-text message (plaintext) into a data
stream which looks like a meaningless and random sequence of
bits (ciphertext).
• Decryption: Reverses that process, cyphertext -> plaintext.
• Cryptographic Algorithm, aka a cipher: A mathematical function
that tells us how to do these transformations. A set of rules or
operations.
• Key: Mixed in with the plaintext to produce the cyphertext, or to
reverse the process.
Crypto 101
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 418
CONTENT
Some more definitions, this time of more advanced terms.
It is critical to understand the difference between symmetrical and asymmetrical
cryptography, as this is the fundamental basis for modern cryptography.
The main issue with symmetrical cryptography involves key management, spe-
cifically, the distribution of keys. Asymmetrical cryptography solves this prob-
lem, and brings other interesting properties along.
1. Continue definitions.
Module 14: Crypto & PKI
mGovernment 419
• Symmetrical Encryption: Uses the same key to encrypt and to
decrypt.
• Cypher is normally published.
• Sender and receiver use a common key.
• Key is secret.
• Asymmetrical Encryption: Uses one key to encrypt, and a separate
paired key to decrypt.
• Cypher is published
• Sender and Receiver each have two keys, a key pair
• By convention, one key is public, the other is private
• Encrypt with one, decrypt with the other key in the pair
Crypto 102
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 420
CONTENT
We take the basic principle of asymmetrical cryptography that we introduced on
the previous slide, i.e. that you encrypt with one key, and decrypt with a different
but paired key, and we combine that with some conventions and practices to get
Public Key Cryptography.
Let’s use an example:
Alice and Bob wish to communicate securely. Each generates a key pair, and
they each designate one of the paired keys their Public Key, and the other key in
that pair their Private Key.
Both publish their public keys, and keep their private keys secret, sharing them
with no one.
For Alice to send Bob a message that only Bob can read, she encrypts it with his
public key. Since only Bob has access to the paired private key, he, and only he,
can then decrypt Alice’s message to him with that private key. No one but Bob
can do this, so this provides confidentiality.
1. Explain the basics Public Key Cryptography building on the definitions.
Module 14: Crypto & PKI
mGovernment 421
Asymmetric Cryptography + conventions and practices = Public Key
Cryptography.
• Uses two separate, but paired keys:
• Public Key – This key can be published.
• Private Key – Only you should have access to this key.
• Data encrypted with one key can only be decrypted by the other
key.
Public Key Cryptography
Data encrypted with your
Is decrypted with your
Who encrypts this data?
Who can read this data?
What purposedoes this serve?
Public Key Private Key Anyone Only You Confidentiality
Private Key Public Key Only You Anyone Authenticity
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 422
CONTENT
Alice could also send Bob a message encrypted with her private key, which only
she has. Bob (or anyone else) can decrypt that message with Alice’s public key
and know that only Alice could have sent it. Since anyone can have Alice’s public
key, there is no confidentiality, but there is authentication, because only Alice
has the ability to encrypt a message with her private key.
We can combine these two operations….. if Alice wishes to send Bob a private
message, and wants Bob to know that she, and only she, sent it.
• Alice, in this order:
• Encrypts the message with her private key, which only she can do,
effectively signing it.
• Encrypts the result again with Bob’s Public Key, so that only Bob can
decrypt and read it.
• Bob reverses the process:
Starting with the encrypted message, he:
• Decrypts it with his private key, which only he has. He can now read the
contents.
• Decrypts the resulting content with Alice’s public key, verifying that Alice
“signed” it, and that the message could only come from her.
The table at the bottom of the slide re-states these properties.
Module 14: Crypto & PKI
mGovernment 423
Asymmetric Cryptography + conventions and practices = Public Key
Cryptography.
• Uses two separate, but paired keys:
• Public Key – This key can be published.
• Private Key – Only you should have access to this key.
• Data encrypted with one key can only be decrypted by the other
key.
Public Key Cryptography
Data encrypted with your
Is decrypted with your
Who encrypts this data?
Who can read this data?
What purposedoes this serve?
Public Key Private Key Anyone Only You Confidentiality
Private Key Public Key Only You Anyone Authenticity
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 424
CONTENT
Lets continue the conversation and examples of public key cryptography from
the previous slide, and focus on the digital signature.
Since only you should have access to the private key in your pair, when you
encrypt something with it, you have effectively signed it.
Anyone who can access your public key can decrypt this message, thus verifying
your signature.
It is critical to maintain the private key properly. If it is shared, leaked or stolen,
we loose the essential properties if the system.
This also provides us the property of non-repudiation, which we will discuss in
detail on the next slide.
1. Continue the discussion of Public Key Cryptography, focusing on digital
signatures.
Module 14: Crypto & PKI
mGovernment 425
• Digital Signatures
• Since only you have access to it, when you encrypt data with your
private key, you are effectively signing the data.
• This signed data can be decrypted with only your public key –
which anyone can have.
• Since only you should have access to your private key, any data
that has been encrypted with it is confirmed to have originated
from you.
This provides a property called nonrepudiation
Public Key Cryptography (2)
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 426
CONTENT
Nonrepudiation is an essential property that cryptography provides which
enables a lot of things, not the least of which are legally binding digital signatures
and financial transactions.
The term originates from the law.
It works like this: Since only you have access to your private key, any message
or data encrypted with your private key must have come from you. You cannot
deny that it did, because only you have the ability to encrypt with your private
key.
Again, it is critical to maintain control of the private key in the pair, otherwise we
loose this property as well as the ones previously discussed.
1. Introduce Nonrepudiation.
Module 14: Crypto & PKI
mGovernment 427
• Originates from law practices (lawyers).
• “Non” – meaning “No”.
• “Repudiation” – meaning “denial”.
• “Nonrepudiation” – “No denial”.
• Nonrepudiation means there can be “no denial” that data which
has been digitally signed with your private key originated from
you.
Nonrepudiation
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 428
CONTENT
As you can imagine, the management of keys in this kind of a complicated
system becomes a problem.
As stated on the slide, we need assurance that your key pair was actually
generated by you.
We solve that with a Public Key Infrastructure, which is a set of conventions and
procedures that binds a lot of components together.
We will explore further on the next two slides.
Module 14: Crypto & PKI
mGovernment 429
• How do we know that the public key we obtained actually belongs
to the person we want to send encrypted data to?
• How do we know that the public key doesn’t belong to someone
trying to steal confidential information?
A Public Key Infrastructure (PKI) solves this problem
Public Key Management
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 430
LEARNING OBJECTIVES
CONTENT
Here we define some more terms we need, and begin the discussion which the
graphic on the next slide will make clear.
The Registration Authority or RA actually verifies or validates the identity of the
person or entity. The degree of diligence that the RA devotes to this validation
is the basis for the strength of the assertions. More diligence means stronger
assurance of the identity, and we can therefore trust it more. This level of
diligence is typically documented in a Certificate Practices Statement.
The CA actually performs the operations to create the digital certificates at the
direction of the RA. The CA signs the public key of the validated entity with the
CA’s private key, thus binding the verified identity to the public key, creating a
Digital Certificate.
The VA maintains copies of the certificates, and validates them on request.
In practice, these three logical entities are frequently combined into one
(commercial or government) entity.
It will all make sense after the next slide.
1. Understand PKI Roles.
Module 14: Crypto & PKI
mGovernment 431
There are specific roles and functions within a PKI:
• Registration Authority (RA):
Conducts an investigation to validate the identity of the person re-
questing a public/private key pair
• Certificate Authority (CA):
Certifies the identities of the owner of a public key by signing their
public key with the CA’s private key
• Validation Authority (VA):
• Validates supplied keys against a trusted resource
• An single organization can fulfill all three of these roles
(Symantec, Comodo Group, Emirates ID, etc.)
PKI Roles or Entities
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 432
CONTENT
<This slide is very animated and builds in the following way>
Start with Bob, who wants to be able to communicate securely. Note that in this
example, Bob has already generated his key pair.
<CLICK>
Introduce the three entities we talked about on the previous slide the RA, the CA,
and the VA. Bob sends a request for a digital certificate to the RA.
<CLICK>
The RA follows the procedures in their Certificate Practices Statement, and
assures itself that Bob really is BOB. They direct the CA to issue a certificate.
<CLICK>
The CA generates and signs the Certificate by signing Bob’s private key, sends it
to Bob, and to the VA
1. Introduce a PKI and walk through an example.
Module 14: Crypto & PKI
mGovernment 433
Public-Key Infrastructure (PKI)
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 434
CONTENT
<CLICK>
Now lets introduce someone Bob has a need to communicate securely with, his
bank.
<CLICK>
Bob wants his bank to transfer money from one account to another. He sends a
message to the bank, signed with his private key.
<CLICK>
The Bank contacts the VA and asks them to validate that Bob signed the message.
<CLICK>
The VA validates the signature, and returns an “OK” to the bank
<CLICK>
Now, how does all this work in the UAE?
<CLICK>
Each holder of an Emirates ID is already enrolled in this system, and the Emirates
ID card contains a digital certificate.
Module 14: Crypto & PKI
mGovernment 435
Public-Key Infrastructure (PKI)
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 436
CONTENT
The people of the UAE have a huge advantage in that the EIDA is in place and
every citizen and resident is issued an Emirates ID. That Emirates ID has an
embedded smart chip, and on that chip are a public / private key pair, the public
key signed by EIDA.
The hardest part of establishing a PKI is issuing the certificates to the users. This
is already done in the UAE.
Several projects will come together in late 2014 and forward to extend this into
the mobile world. The hardest part of the problem, validating the identities and
issuing the certificates (ID Cards) is already done.
1. Discuss the role of Emirates ID Authority.
Module 14: Crypto & PKI
mGovernment 437
This is how Emirates ID works
The Emirates ID card contains a unique pair of encryption keys in the
on-board smartchip, issued by the EIDA
• What does that mean for mGov?
• The hardest part of Identity Management problem is solved.
• Users can register with your mGov service simply using their
Emirates ID.
• Users can receive encrypted messages from you.
• Users can send digitally signed messages to you.
Role of EIDA
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 438
CONTENT
Review the Objectives (re-read the slide).
1. Understand basic cryptography.
2. Understand the difference between symmetric and asymmetric encryption.
3. Understand the fundamentals of a PKI.
mGovernment 439
Module 14 : Crypto & PKI
Review of Objectives
• Understand basic cryptography.
• Understand the difference between symmetric and asymmetric
encryption.
• Understand the fundamentals of a PKI.
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 440
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 441
Module 14: Crypto & PKI
Quiz – Question 2
Quiz – Question 1
1. Public Key Cryptography is a method of safely sharing
symmetric encryption keys and allowing us to digitally sign
information.
Select one:
a. This statement is 100% accurate.
b. Public Key Cryptography does not use symmetric encryption.
c. Public Key Cryptography replaces the need for digital
signatures.
d. The correct name is “Private Key Cryptography”.
2. The role of the RA (Registration Authority) in the PKI is to:
Select one:
a. Verify the identity of the person or entity according to the
RAs Certificate Practice Statement.
b. Create the Digital Certificate by signing the entity’s public
key.
c. Maintain copies of certificates and validates them upon
request.
mGovernment 4 4 2
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 4 4 3
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 444
CONTENT
This module contains an introduction to and discussion of SSL / TLS.
This is not in any way exclusive to peculiar to Android, but we need to understand
it for all platforms and the bigger picture.
THEMES
GLOSSARY
• Applications, Security.
SSL: Secure Sockets Layer.
TLS: Transport Layer Security.
Module 1, mGov Training Introduction
mGovernment 4 4 5
Module 15: SSL / TLS
SSL / TLS
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 446
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Introduce SSL / TLS.
2. Understand what SSL / TLS does for us.
3. Understand the role of SSL / TLS in mobile computing.
Module 15: SSL / TLS
mGovernment 447
Objectives
• Introduce SSL / TLS.
• Understand what SSL / TLS does for us.
• Understand the role of SSL / TLS in mobile computing.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 448
CONTENT
The acronyms SSL and TLS are used interchangeably, but they are not exactly
he same.
SSL was invented by Netscape Communications for use in the Netscape Web
Browser.
Version 1.0 was never released to the public.
Version 2 was released, but issues were discovered.
Version 3 was also released, and then was moved into the IETF standards track
for maintenance and enhancement.
The working group renamed it TLS, which is what it remains today.
1. Introduce SSL and TLS.
Module 15: SSL / TLS
mGovernment 449
TLS / SSL
• TLS – Transport Layer Security
• SSL – Secure Sockets Layer
• SSL TLS
• SSL evolved into what is known as TLS today.
• SSL is an older protocol which is still supported via TLS.
• Most new devices implement TLS (not SSL).
• When most people say “SSL”, they mean “TLS”.
• Unless we get into very detailed discussions about older
technology, it is safe to think that TLS and SSL are the same thing.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 450
CONTENT
What does it really do for us?
In no particular order, i.e., some of these protections may be more important at
one time than another, depending on the use:
It encrypts the communications CHANNEL between the client and the server.
Data in Transit (DIT) between the two is private, i.e. safe against INFORMATION
DISCLOSURE, and at least partially protected against TAMPERING and SPOOFING.
At the most basic level, it authenticates the server to the client. The client can
validate the identity of the server.
It can also authenticate the identity of the client to the server. This is optional
and client side authentication is traditionally regarded as difficult because of
scalability issues.
In the Emirates, that problem is largely solved by EIDA and government agencies
will be able to validate client (user) identity eventually over the FedNet.
1. Discuss the two basic benefits of SSL / TLS.
Module 15: SSL / TLS
mGovernment 451
• Encrypts the communication channel HTTP through TLS / SSL
becomes HTTPS
• Authenticates server to client
Client accessing https://www.foobar.com knows they are
connecting with “FooBar Corporation”, and that only foobar.com
can understand (decrypt) the request
• IF using client side certificates, the server can authenticate the
client This is not common, but technically possible
What does TLS / SSL do?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 452
CONTENT
Lets apply the STRIDE model we discussed previously.
Looking at the DATA, METHOD AND CHANNEL, we can see that TLS protects
against the threat of INFORMATION DISCLOSURE in the CHANNEL, and provides
partial mitigation against SPOOFING and TAMPERING.
1. Analyze SSL / TLS using the STRIDE Threat model.
Module 15: SSL / TLS
mGovernment 453
TLS / SSL Services
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 454
CONTENT
With SSL / TLS, the client and server negotiate until they agree on compatible
parameters.
The client begins, requesting an SSL / TLS connection, and supplying certain
parameters.
The server responds with its capabilities, and its digital certificate.
Most important step: The client validates the certificate. At a minimum,
the certificate should be valid, current, correctly signed with the private key
corresponding to a digital certificate from one of the CAs which are pre-loaded
in the client (browser, mobile device, etc.). Continuing certificate validation,
the Canonical Name (aka CNAME or CN) within the certificate MUST match the
domain name of the server. If it does, the client has assurance as to the identity
of the server.
At that point, the client generates a random session key, encrypts it with the
public key of the server from the server’s certificate, and sends the encrypted
key to the server. The client is finished at this point.
The server is finished negotiating at this point. After it decrypts the random
session key with the server’s private key, the client and server both now have
that key, and can now exchange information securely by encrypting the data
with the session key.
1. Walk through the simple SSL / TLS Handshake.
Module 15: SSL / TLS
mGovernment 455
TLS / SSL Handshake
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 456
CONTENT
Mutual Authentications means that both parties have assurance as to the
Identity of the other.
In SSL / TLS, this requires clients to have digital certificates of their own.
The negotiation works the say was as on the previous side, except after the client
validates the server certificate and generates, encrypts and sends the session
key to the server, it also sends a copy of its client certificate. The server validates
the client certificate much as the client with the server certificate. At this point,
both parties have assurance as to the identity of the other party.
This is the “crown jewels”, and the UAE are very well positioned to get there since
the Emirates ID in the hands of every citizen or resident contains a client digital
certificate.
1. Continue and expand from the previous slide to include use of Client
Certificates in the handshake.
Module 15: SSL / TLS
mGovernment 457
Mutual Authentication
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 458
CONTENT
I can think of virtually no cases where it does not make sense to use TLS always.
“Mixed modes” mean that some traffic is encrypted, some is not. It adds
significant complexity to the logic of both the client and back end, and introduces
the possibility of sending sensitive data unencrypted / unprotected, so it is best
to avoid it.
“SSL / TLS Always” is the most secure, and the simplest approach for the
programmer. Mixing secure vs. non secure modes mean that both the client and
server have to implement some kind of traffic control mechanism to manage
which data goes over which channel. It is much easier to just use a single, secure
channel.
If you must use mixed channels for some reason, make sure the secure channel
is used for:
• All login attempts
• The duration of all authenticated secure sessions
• Transactions containing sensitive data
1. Recommend that SSL / TLS always be used.
Module 15: SSL / TLS
mGovernment 459
Always
• Simplest approach – Encrypt all communications with TLS / SSL.
Avoid mixed mode!
• At the very least, use TLS / SSL for:
• All login attempts.
• The duration of all authenticated secure sessions.
• Transactions containing sensitive data.
When should I use TSL / SSL?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 460
CONTENT
The graphic serves to illustrate that even the best tools, in this case, a bicycle
chain and lock are useless if not used correctly.
Among other things, the client and server have to be in sync.
Synchronization means, among another things, having clocks that are correct
(mostly) and certificates that are valid, and signed by CAs recognized by the oth-
er party.
Valid in this sense means:
• The date when the certificate was issued / became valid is in the past.
• The date when the certificate expires is in the future.
Both will cause errors. Your code should handle these and any other certificate
validation errors, not just proceed anyway.
1. Emphasize that SSL / TLS must be used correctly to provide the benefits.
Module 15: SSL / TLS
mGovernment 461
• Server & Client must be
synchronized.
• Must also synchronize with:
• Client Certificate Authority
Root.
• Server Certificate Authority
Root.
What can go wrong?
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 462
CONTENT
This is a partial listing of some certification validation errors. Client and server
code must handle these errors, and not proceed with the handshake if they
occur.
1. List some SSL validation errors and emphasize that they must be handled.
Module 15: SSL / TLS
mGovernment 463
SSL Error Handling
Constants
int SSL_DATE_IN-
VALID
Certificate date is invalid
int SSL_EXPIRED Certificate expired
int SSL_IDMIS-
MATCH
Hostname mismatch
int SSL_INVALID Generic error
int SSL_MAX_ER-
ROR
(deprecated)
int SSL_NOTYET-
VALID
Certificate not yet valid
int SSL_UNTRUST-
ED
Certificate authority not trusted
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 464
CONTENT
Here is a checklist for deploying TLS in your applications:
The last two bullets are particularly important. A lot of the digital world was
found to be (and remains) vulnerable to the heartbleed problem in OpenSSL. It
is a lot more widespread that most people realize, and will be with us for a long
time in legacy equipment and software.
Testing did eventually uncover it.
1. Present a checklist for the use of the developer and security professional to
use when building / checking apps.
Module 15: SSL / TLS
mGovernment 465
• TLS / SSL only – no “mixed mode” (unsecured, unauthenticated
network communications)
• Verify certificates
• Verify name (CN, Canonical Name)
• Know your errors, and handle them appropriately
• Verify the CAs in the root for devices
• Verify the server side
• Test! Never assume “it just works”
• Remember: Heartbleed
App Checklist
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 466
CONTENT
Review the Objectives (re-read the slide).
1. Introduce SSL / TLS.
2. Understand what SSL / TLS does for us.
3. Understand the role of SSL / TLS in mobile computing.
mGovernment 467
Module 15 : SSL / TLS
• Introduce SSL / TLS.
• Understand what SSL / TLS does for us.
• Understand the role of SSL / TLS in mobile computing.
Review of Objectives
It is now time to review your knowledge
of this material
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 468
Quiz – Question 1
1. TLS / SSL mitigates against which of the STRIDE Threat Model
threats in the channel (pick three)?
Select one or more:
a. Spoofing.
b. Tampering.
c. Repudiation.
d. Information Disclosure.
e. Denial of Service.
f. Elevation of Privilege.
Module 1, mGov Training Introduction
mGovernment 469
Module 15: SSL / TLS
Quiz – Question 3
Quiz – Question 2
2. SSL protects which part of the application Attack Surface.
Select one:
a. Message Data
b. Application Method
c. Communication Channel
d. None of the Above
3. When authenticating a SSL connection to amazon.com which
part of the certificate is authenticated?
Select one:
a. CP= amazon.com.
b. notDuring=May 17 00:00:00 2013 GMT.
c. CN= amazon.com
d. None of the Above.
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 470
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 471
Module 15: SSL / TLS
Quiz – Question 4
4. Client side SSL certificates are used for:
Select one:
a. Authenticating the server.
b. Authenticating the client.
c. Both of the above.
d. Neither of the above.
mGovernment 4 7 2
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 4 7 3
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 474
CONTENT
This module continues the discussion of mobile platforms by discussing iOS
(iPhone) security mechanisms.
There are fewer slides here than in the Android module, but a lot of the basics we
covered with Android apply here as well.
THEMES
Glossary
• Architecture, Applications, Security.
iOS: Apple’s Operating System for the iPhone and iPad
• Accessed through the web browser
• Deployed over Internet
• Can develop/design one application for all platforms
• A cross-platform mobile application
• Provides uniformity across all platforms
• Near-instant updates
• Updates to the application are actually updates to the website,
happening on the back-end
Introduction
SDLC: Service Delivery Lifecycle
Glossary
Module 16: iOS Security
iOS Security
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 476
LEARNING OBJECTIVES
CONTENT
Let’s discuss incentives. It is important to understand a vendors incentives, and
business models to understand some of the architecture and design decisions
they have made.
For example, Apple leveraged the existing heritage of Macs and technical skills
of it’s developers to make the decisions to use Objective C as the development
language. In doing so they inherited the problems with C family languages…
because they were incentivized to use the legacy skills of the existing apple
developer base.
What are the motivations (incentives) for Apple? They sell devices, they develop
the UI, and the resulting user experience is very smooth. They are incentivized
to keep it that way.
By doing so, they can sell more devices…and songs and videos via iTunes, the
biggest money maker for Apple. Apple revolutionized the mobile market with
the iPhone, and no one will argue that point, but perhaps their most brilliant
decision was to tie the iPhone so tightly to iTunes. The placed a music store in
your hands, and turned the music industry upside down in the process.
1. Discuss Incentives and their influence on design decisions.
Module 16: iOS Security
CONTENT
• Comparison of platforms reveals differences.
• Understanding the motivations, business models and inventives of
Apple vs. Google helps us understand the differences.
Incentives
Google’s revenue is from advertising…that’s why they do it the way they do it.
They want to maximize the number of eyes seeing Google advertising, so they
give away the operating system, and make it trivially easy to become an Android
app developer.
Apple sells hardware, music and videos. They give away virtually nothing.
Google (for the most part) does not sell hardware, gives away the OS to
manufacturers and individuals. They sell adds, so more eyes on (Android) screens
is better for them.
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 478
LEARNING OBJECTIVES
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Understand the architecture of the iOS operating system.
2. Understand the security model.
Module 16: iOS Security
• Understand the architecture of the iOS operating system.
• Understand the security model.
Objectives
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 480
LEARNING OBJECTIVES
CONTENT
Compare the architecture with Android on this and the next slide.
This is similar to the Android architecture of Activities, Services, Content Providers,
etc., and as of the 2014 World Wide Developer Conference, it seems like they are
moving more in the Android direction of more integrated applications.
It’s layered model, similar to Android’s but a little less cluttered.
1. Introduce the iOS architecture.
Module 16: iOS Security
iOS Layered Architecture
• Cocoa Touch
App development framework
• Media
Multimedia, audio, visual, graphics
• Core Services
Networking, iCloud, location,
Security APIs
• Core OS
Low level, Bluetooth LE, Security
services, certificate, key
management
Like the Android slide, except
designed in Cupertino…..
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 482
CONTENT
Starting at the physical layer and working up, we see some differences with
Android.
First, Apple designs and manufactures (OK, they contract that out) their own
hardware. Unlike google, they are in control. At any given time, there are ~3
“current” device designs in the market, and practically one OS version, whatever
is current.
There is a crypto engine with an embedded Apple certificate in the hardware, so
on a non-jailbroken device, there is the ability to validate that applications are
digitally signed by an Apple-issued and signed certificate.
The kernel is Unix based, so the low level Unix type file permissions that we are
used to on Android are here as well.
The filesystem is encrypted, with the OS and the userspace segregated.
Applications run in individual sandboxes, like Android.
There is no removable storage, so we don’t have to worry about it encrypting
data stored there.
A secure element is present with iPhone 6 and later.
1. Introduce the iOS Security Architecture.
Module 16: iOS Security
Glossary
• Apple’s model:
• Architecture.
• Encryption.
• Data Protection.
• Network Security.
• Physical.
iOS Security Architecture
Jailbroken: an iOS device which has been exploited to allow the installation of
applications from other than iTunes amon other things.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 484
CONTENT
The graphic depicts the lifecycle of an iOS application from startup, being shifted
into background, back to the foreground, and quitting.
When shifting from one app to another (using one app and the phone rings) and
back, the transition when it comes back is very quick. The app you are returning
to is non-responsive initially… ever wonder why?
You are initially returned to a screen snap shot of the previous application, not
the app itself. This was done to enhance the user experience, giving the user the
perception of snappy performance as the iPhone switch contexts from one app
to another.
This potentially could contain very sensitive information like your bank account
number, depending on the application.
Remember incentives?
1. Expose the iOS backgrounding behavior as a potential channel for
information leakage.
Module 16: iOS Security
CONTENT
Application Lifecycle
The security professional has to worry about where that snap shot of sensitive
information was kept. If it’s in memory – what part of memory. If it’s there and
accessible…it will be accessed.
Remember the STRIDE threat model. This is a potential Information Leakage
threat from the Method.
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 486
CONTENT
Android applications are written in java, and run in a java virtual machine called
Dalvik. One of the benefits of this is that the environment manages the memory
for the developer.
Up until June 2014, the only programming language for iOS applications was
Objective C, which shares some of the traditional C family languages problems.
The most recent Objective C compiler takes care of some of these issues for you,
but not all.
iOS applications, and iOS developers are responsible for memory management
at the end of the day.
As of the June 2014 WorldWide Developer Conference, Apple announced a new
language “Swift”
It remains to be seen what the security implications of this will be, but things
will probably change. At the minimum, for some time at least, developers will
probably be able to use either language for iOS apps
1. Contrast memory management on iOS with Android.
Module 16: iOS Security
• iOS applications must manage memory:
• Programming language is Objective-C.
• Newer Compiler handles some, but not all issues.
• Bugs: Buffer overflows, integer overflows, double free, format
strings.
• Security features include:
• Data Execution Protection (DEP).
• Address Space Layout Randomization (ASLR).
• Rules:
• Do not allocate memory until user is authenticated.
• Protect keys & references to keys.
• Utilize randomized memory.
Memory
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 488
CONTENT
Security features include ASLR like with Android, but add Data Execution
Protection (DEP). Memory is designated executable or not, making the attackers
life more difficult.
General programming rules apply here as well. Secure programming is mostly
just good programming.
Module 16: iOS Security
• iOS applications must manage memory:
• Programming language is Objective-C.
• Newer Compiler handles some, but not all issues.
• Bugs: Buffer overflows, integer overflows, double free, format
strings.
• Security features include:
• Data Execution Protection (DEP).
• Address Space Layout Randomization (ASLR).
• Rules:
• Do not allocate memory until user is authenticated.
• Protect keys & references to keys.
• Utilize randomized memory.
Memory
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 490
LEARNING OBJECTIVES
1. Discuss storage with iOS.
• On the device, the primary difference is that there is no removable storage
like on Android and the other platforms.
• Internally, we have access to Plists, which typically store configuration
information.
• As with Android, there is a SQLite database available.
• The Keychain is an apple innovation that we will discuss in a few slides
• iOS has an integrated certificate store, and the normal assortment of buffers
and caches.
• Off the device, the innovation is the iCloud. This requires networking
access to function, and over time, applications have taken more and more
advantage of it.
CONTENT
Module 16: iOS Security
• On device
• Files, Plists
• SQLite
• Keychain
• Certificate store
• Buffers & caches
• Off device
• Networking
• iCloud
• Streams
• P2P
• Push Notifications
Storage
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 492
CONTENT
What’s involved with getting an app into the iTunes app store?
First the developer must register with Apple and pay a fee, $100 US currently.
Apple issues the developer a digital certificate for the purpose of signing apps.
The certificate chains back to an Apple CA, as does the certificate embedded in
the hardware, so the iPhones and iPads can validate that they are loaded apps
from known developers.
There is a set of standards published by Apple for apps. This tends to be a moving
target, but Apple will check an app before it accepts it. It’s reasonable to assume
that they are performing some static analysis of the source code, so they are
trying to be proactive and keep the bad stuff out of the iTunes store.
They are of course also concerned about usability, a User Experience consistent
with their guidelines, and revenue issues.
Contrast this with Google / Android approval model, where apps are apparently
more readily accepted into the Play store.
Apple model: Keep bad stuff out of the store from the beginning.
Android model: Pull it out when discovered, lots more apps to encourage
adoption.
1. Compare and contrast the process and policies for getting an app accepted
by Apple vs. by Google.
Module 16: iOS Security
What security can you expect
from App Store review
process?
• In general, Apple is likely to be
more concerned with usability and
revenue than security.
• Reasonable to assume some static
analysis and no dynamic analysis
• Not perfect, but overall result is
far better than Android at keeping
malware out of its App Store
App Store Process
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 494
CONTENT
Decompilation of binary applications is possible on any platform, but it rarely
yields the kind of treasure we find on the Android platform.
It is definitely possible on the iOS platform, just not as easy as Android.
Commercial and free tools exist, and it is possible to patch (trojan) binaries, but
they should be caught at install time when their signature does not validate.
The Good news: this does not yield a human readable block of source code like
Android.
But, if you have ever seen a hacker (reverse engineer) blow through assembly
code with IDAPro, you begin to understand that this IS possible.
1. Discuss decompilation of iOS apps.
Module 16: iOS Security
Glossary
IDA Pro: Interactive Disassembler used for disassembly and reverse engineering
of binary applications.
• Assume iOS applications can and will be reverse engineered by
attackers…but not as easily as Android.
• Free and commercial tools available.
• Information can be harvested from binaries.
• Binaries can be patched by attackers to create trojanized applications.
• It is more difficult than Android, but possible.
Decompilation
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 496
CONTENT
The model for signing code on iOS is similar to that for Android, but with two
large differences:
• First, with iOS, Apple as the hardware manufacturer embeds their own
certificate in the hardware. iOS uses this to validate the signature on the apps.
• Second, Apple requires developers to register with them and to pay a fee.
Apple then issues each developer a digital certificate signed by Apple. That
signature is checked by Apple when the developer submits the app to them,
when it goes in the iTunes store, and then the iPhone loads it. It also is used for
these other purposes.
This is overall a much more secure system than is in place with Android, and is
similar to what is in place with Windows phone and Blackberry.
1. Discuss the code signing process for iOS apps, and how it differs from the
Android / Google process.
Module 16: iOS Security
• Registration and verification process required for developers and
for all third party applications
• Required for App Store and iOS execution
• Unlike Android, executable code must be signed with an Apple
issued certificate
• Signature used for
• LoadingUpdate
• Authentication
• Runtime Integrity
• Sandboxing
Code Signing for iOS
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 498
CONTENT
Prior to the iPhone 6, the keychain on iOS was as close as we come to having a
secure element on the iOS platform without external hardware, but it is different.
External hardware with iPhones is an issue:
• Ugly, spoils the aesthetics, makes the phone less desirable to the user
• For the data thief, it screams “steal me”
Speculation is that Apple may include a secure element in future versions.
They have an alternative to NFC, so it is not clear where they will go. Included in
iPhone 6 and later.
In the mean time, the keychain can securely store (strong) keys for the user on
a per-application basis, and supply them automatically when the user accesses
the app.
The protection is only as good as you protecting the device. If the device is
stolen, the attacker may be able to use your stored keys.
There is a flow chart on the next slide which shows how the keychain works in
practice.
1. Expose and describe the Keychain.
Module 16: iOS Security
• Protected storage.
• Important note – the protection is only as good as what protects
the device: physical access and passcode.
• Key interfaces.
• Add and update keys.
• Search for keys.
• Entitlement based access through keychain-access-groups.
Keychain
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 500
CONTENT
This is a flow diagram of how the keychain works with iOS apps.
Follow it through, it’s pretty intuitive.
1. Show a flow chart of the keychain in operation.
Module 16: iOS Security
• Try to locate stored key
(SecItemCopyMatching).
• Otherwise prompt user and if
login successful, ask to store with
with either:
• SecItemAdd.
• SecItemUpdate.
Keychain In Practice
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 502
CONTENT
SSL and TLS clients and servers negotiate during the handshake. One of the
things selected is SSL vs TLS and which version.
Systems should be configured to NEVER negotiate below SSL v3, and the latest
version of TLS is always prefered.
DTLS is Datagram TLS, or TLS for UDP as opposed to TCP.
The same issues and considerations apply here as for Android, except Apple does
not, and never did use OpenSSL, so the heartbleed bug was not here.
1. Discuss SSL / TLS on iOS.
Module 16: iOS Security
Glossary
DTLS: Datagram TLS.
TCP: Transmission Control Protocol, session-oriented transport protocol from
the Internet Suite.
UDP: User Datagram Protocol, sessionless transport protocol from the Internet
Suite.
• iOS supports SSL v3, TLS 1.1 & 1.2, and DTLS.
• Considerations.
• Used for one way (usually) or two way (infrequently) authentication.
• Encrypt communications channel.
• Coordinating Solution.
• Check hostname.
• Ensure exceptions are managed.
• Complications.
• Error handling.
• Testing issues for SSL clients.
• Mixed mode issues.
• Ensure certificate chains and roots are deployed.
TLS / SSL
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 504
CONTENT
The sandbox here works a little differently, and is not considered as strong as the
Android one, but it is here.
1. Discuss the Sandbox as implemented on iOS.
Module 16: iOS Security
• Boundary defined by digital signature.
• Protected by DEP (Data Execution
Protection) and ASLR (Address Space
Location Randomization).
• Does not limit network
communications, sockets, or
interaction with system services.
iOS Sandbox
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 506
CONTENT
Review the Objectives (re-read the slide).
1. Understand the architecture of the iOS operating system.
2. Understand the security model.
Module 16: iOS Security
• Understand the architecture of the iOS operating system.
• Understand the security model .
Review of Objectives
It is now time to review your knowledge
of this material
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 508
Quiz – Question 1
1. iOS applications are written in:
Select two:
a. A Java-like language.
b. C#.
c. Python.
d. Objective C.
e. C++.
f. Swift
Module 1, mGov Training Introduction
mGovernment 509
Module 16: iOS Security
Quiz – Question 3
Quiz – Question 2
2. ASLR is: (pick the best answer):
Select one:
a. Only used on iOS platforms.
b. Only used on Android platforms.
c. Used to protect against buffer overflows.
d. Exclusive to the Blackberry Enterprise Server.
3. All iOS Applications may be signed by a third party OpenSSL
certificate to be deployed in the Apple App Store.
Select one:
a. True
b. False
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 510
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 511
Module 16: iOS Security
Quiz – Question 4
4. All iOS Applications must be signed by an Apple issued
certificate to be deployed in the Apple App Store.
Select one:
a. True
b. False
mGoverment 5 1 2
End of Module
mGoverment 5 1 3
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 514
CONTENT
This module continues the discussion of mobile platforms by discussing Windows
Phone security mechanisms.
There are fewer slides here than in the Android module, but a lot of the basics we
covered with Android apply here as well.
THEMES
• Architecture, Applications, Security.
• Accessed through the web browser
• Deployed over Internet
• Can develop/design one application for all platforms
• A cross-platform mobile application
• Provides uniformity across all platforms
• Near-instant updates
• Updates to the application are actually updates to the website,
happening on the back-end
Introduction
SDLC: Service Delivery Lifecycle
Glossary
Module 17: Windows Phone Security
Windows Phone Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 516
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Understand security model and peculiarities of Windows Phone.
Module 17: Windows Phone Security
mGovernment 517
• Understand security model and peculiarities of Windows Phone.
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 518
CONTENT
Windows phone code signing requirements are similar to the Android / Apple
requirements, with the following exception:
Microsoft requires that developers sign code, and that they obtain a code signing
certificate from a designated 3d party, Symantec at this point.
This signature model is stronger than Android’s, but weaker than iOS and
Blackberry because there is no certificate embedded in the handset at
manufacturing time.
Each application runs in a sandbox, similar to the other platforms, and application
are run by the Execution Manager.
1. Introduce the Windows Phone Platform.
Module 17: Windows Phone Security
mGovernment 519
• Windows Phone store enforces mandatory code signing
• Applications are run by the Execution Manager
• Each application runs in its own sandboxed process
Windows Phone Platform
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 520
CONTENT
There is virtually nothing new here, the same considerations as the other
platforms. So let’s review them:
• Use SSL / TLS, Always.
• Do not allow use of SSL older than SSLv3, and prefer the latest version of TLS.
• Validate certificates and certificate chains, including matching CN to the
hostname.
• No Mixed Modes.
1. Discuss Network Security on Windows Phone.
Module 17: Windows Phone Security
mGovernment 521
• Ensure all communications are over TLS / SSL.
• Ensure that communication do not support older (SSL v2) ciphers.
• Ensure certificates and certificate chains are validated.
• Ensure host names match.
• Ensure no mixed mode (SSL & non-SSL) is supported.
Network Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 522
CONTENT
Pay particular attention to artifacts in these folders left over from operations
(temp files) and installation.
The windows phone is a derivative of the modern MS windows OS, so the crypto
library is there, and good. Use it to protect stored data DAR), as it’s not done
globally or automatically.
Windows phones, like Androids typically have removable SD cards, unlike iOS.
Data stored there is not protected unless done so explicitly by the application.
1. Discuss the peculiarities of data security on Windows Phone.
Module 17: Windows Phone Security
mGovernment 523
Data persistence
• Installation folder.
• Local folder.
• Media library.
• External Storage (SD Card) Win32 APIs (Windows 8).
Data Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 524
CONTENT
Review the Objectives (re-read the slide).
1. Understand security model and peculiarities of Windows Phone.
Module 17: Windows Phone Security
mGovernment 525
• Understand security model and peculiarities of Windows Phone.
Review of Objectives
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 526
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 527
Module 17: Windows Phone Security
Quiz – Question 1
1. Windows Phone applications must be signed by the developer
with a Microsoft signed certificate.
Select one:
a. True
b. False
mGovernment 5 2 8
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Module
mGovernment 5 2 9
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 530
CONTENT
This module continues the discussion of mobile platforms by discussing
Blackberry and the Blackberry Enterprise Server (BES).
This is a little bit of a different animal in that it is not appropriate to discuss the
blackberry handheld as a standalone. You have to consider the BES, discussed
later.
On the one hand, client platform decisions are largely out of the hands of the
mGov developer / security person, certainly in G2C (government to citizen)
model. On the other hand, in G2G and G2E (Government to government or
employee) that may not be the case, so we’ll talk about this a little.
THEMES
• Architecture, Applications, Security.
• Accessed through the web browser
• Deployed over Internet
• Can develop/design one application for all platforms
• A cross-platform mobile application
• Provides uniformity across all platforms
• Near-instant updates
• Updates to the application are actually updates to the website,
happening on the back-end
Introduction
SDLC: Service Delivery Lifecycle
Glossary
Module 18: BlackBerry Security
BlackBerry Security
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 532
CONTENT
Introduce the Objectives, (read the slide).
This module has these objectives:
1. Understand the security model of the Blackberry.
2. Understand how the Blackberry integrates with the Blackberry Enterprise
Server (BES).
Module 18: BlackBerry Security
mGovernment 533
• Understand the security model of the Blackberry.
• Understand how the Blackberry integrates with the Blackberry
Enterprise Server (BES).
Objectives
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 534
CONTENT
Blackberry is the only one of the platforms we discuss that was designed from
the beginning for government and business use, with security as a primary
consideration from an early point.
EVERY blackberry talks to a Blackberry Enterprise Server, even citizen owned
phones talk to BESs operated by their carrier, in the UAE Du/Etisalat (TRA). The
BES is designed to manage and secure the communications to the handheld,
and the handheld itself.
With Blackberry version 10, the system was redesigned to segregate work from
personal, both apps and data.
The current BES can also do this for Android and iOS devices, and is designed to
help companies / government solve the Bring Your Own Device (BYOD) problems.
1. Expose highlights of the blackberry + BES architecture.
Module 18: BlackBerry Security
mGovernment 535
• It’s all about the BES 10 (BB Enterprise Server)
• Less focused on the BB Smartphone
• Focused on the BES
• Provides a separation between Work and Personal Use
• Example: cannot cut/paste between the two
• Secure, segregated storage
• Designed to be a BYOD manager
• Solves a critical problem for businesses and government
• Plays to RIMs strength - managing the endpoint devices of many
operating systems
• Where is it, what’s running on it, if lost, remote kill the access and
wipe if necessary
Blackberry Security Strategy: “A New Approach”
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 536
CONTENT
This is similar to what we saw on Android and iOS, but goes further in terms of
memory protections and policy controls.
The BES has several hundred policy elements that it can enforce on a configured
and connected device, including iOS and Android devices.
It can do slightly more with a blackberry handheld, but not much.
1. Discuss the access controls of the Blackberry.
Module 18: BlackBerry Security
mGovernment 537
• Blackberry 10 supports ASLR, non executable stack and heap
(tree-based data structure)…the highest key (parent) is the root key.
• Apps use permissions capabilities model to request access.
• Most sophisticated policy set - Resources are partitioned, Active
Directory integration, fine grained access control.
Platform Access Control
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 538
CONTENT
This illustrates how some of those controls mentioned on the previous slide can
work.
1. Give an example of how Platform Access Controls work on the blackberry.
Module 18: BlackBerry Security
mGovernment 539
Platform Access Control permissions model
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 540
CONTENT
The blackberry is designed to store securely to local storace, including (optionally)
to the removable SD card. When an SD card is inserted, the blackberry offers to
encrypt it.
This is very different from other platforms.
The BES can wipe data from a supported and connected device remotely, either
the whole device, or just the “work” area.
Blackberry devices will also wipe themselves automatically after a configured
number of failed login attempts, offering some protection for lost / stolen
devices.
1. Explore how secure storage is different on the blackberry.
Module 18: BlackBerry Security
mGovernment 541
• Passcode protected storage.
• Wipe data remotely:
• Full device.
• Work space only.
• SD Card has support for encrypted storage.
• BES 10.
• Storage separated into base file, work file, personal files.
• Each app runs under unique ID.
• Can manage Blackberry, iOS and Android devices.
Secure Storage
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 542
CONTENT
All communications between the blackberry handheld and its BES are TLS
encrypted. The blackberry is preloaded with the TLS certificate from the BES
server, so it can validate that one sent matched the one stored.
Additionally, BB devices sign and hash messages for additional protection, unique
to this platform.
1. Explore differences in the communications on the Blackberry platform.
Module 18: BlackBerry Security
mGovernment 543
• TLS on Blackberry.
• A device sends a request to the BlackBerry Infrastructure to open a
TLS connection.
• The BlackBerry Infrastructure sends its TLS certificate to the device.
• The device uses a root certificate that is preloaded on the device to
verify the TLS certificate. If the user deleted the root certificate, the
device prompts the user to trust the TLS certificate.
• The device opens the TLS connection.
• Additional message integrity: Blackberry signs and hashes
messages sent to the device using message keys for integrity.
Secure Communications
LEARNING OBJECTIVES
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 544
CONTENT
Review the Objectives (re-read the slide).
1. Understand the security model of the Blackberry.
2. Understand how the Blackberry integrates with the Blackberry Enterprise
Server (BES).
Module 18: BlackBerry Security
mGovernment 545
• Understand the security model of the Blackberry.
• Understand how the Blackberry integrates with the Blackberry
Enterprise Server (BES).
Review of Objectives
QUIZ
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
mGovernment 546
It is now time to review your knowledge
of this material
Module 1, mGov Training Introduction
mGovernment 547
Module 18: BlackBerry Security
Quiz – Question 2
Quiz – Question 1
1. The BlackBerry Enterprise Server (BES) Release 10 is designed
to (pick the one best answer):
Select one:
a. Compete for the mobile smart phone market.
b. Deal with the security challenge of Bring Your Own Device
(BYOD) where the device is used for both personal and work
reasons.
c. Both of the above.
d. None of the above.
2. Which of these platforms signs and hashes messages sent by
the device to the client to ensure integrity
Select one:
a. Windows Phone
b. iOS
c. Android
d. Blackberry
e. All of the Above
f. Both A & B
g. None of the Above
mGovernment 5 4 8
Mobile Security: Keeping Information Secure in the Mobile Age / Student Guide
End of Book
www.government.ae