.NET Mobile Application Development
Security in Mobile and Distributed
Applications
Introduction
 In previous sessions we have considered
> Design of distributed applications
> Application configuration
> Appropriate choice of technology
 In this session we will give an overview of
security in distributed applications
> Authentication and authorization
> Encryption
> .NET support for security
Security Basics
 Security is important in all applications,
particularly those
> with distributed components
> that run on mobile devices
 Need to consider all aspects of security, not just
software
> A system is only as secure as its weakest point
 No system is 100% secure; need to decide
> What level of security is required?
> What risks are acceptable?
Distributed Application
Security
 Key aspects of distributed application security
> Only allowing access to legitimate users
> Granting users rights to perform only the actions they need for their tasks
> Protecting integrity and preventing disclosure of sensitive data
- Mobile devices are easily lost or stolen, and hence easily
compromised
 Addressing these issues requires authentication,
authorization and encryption
 Other issues not considered here relate to security
compromises
> Denial of Service attacks
> Man-in-the-middle attacks, session spoofing, etc
Authentication & Authorization
 Authentication
> Process of determining user’s identity
 Authorization
> Process of assigning permissions and restrictions to an authenticated user
 Required in a secure application, but not sufficient for security
 Two approaches to implementation
> Custom authentication / authorization mechanism
- Usually requires database of users, roles, etc
- Often used in systems with external components
- Can be cross-platform
> Operating system features
- e.g. Integrated Windows authentication & authorization
- Often used for purely internal systems
- Not suitable for cross-platform applications
Example: Windows Authentication
 Windows OS offers authentication and authorization facilities to the
developer in (un)managed code
using System.Web.Services;
using System.Security.Principal;
public class AuthTest : System.Web.Services.WebService {
[WebMethod]
public String CurrentUser{
// Retrieves identity of user used to
// execute this code
return WindowsIdentity.GetCurrent.Name;
}
[WebMethod]
public String CurrentIISUser{
// Retrieves authenticated IIS user
return User.Identity.Name;
}
}
> Support for Windows authentication is automatic with XML Web services
Authentication in Web
Services
 Web service proxy may need to pass user credentials to server before being

granted access to Web service
Proxy.Credentials property
> Defines collection of security credentials.
 Can use
> Current user’s Windows credentials
SomeWebService proxy = new SomeWebService();
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
> Custom credentials
- Can retrieve credentials from user via User Interface
SomeWebService proxy = new SomeWebService();
proxy.Credentials = System.Net.NetworkCredential("name",
"password");
 Proxy automatically passes credentials to server
Authorization & Role-based
Security
 Server needs to determine whether user has sufficient permissions to
perform requested operation
> Role-based security
 Example: Windows authentication
> each role corresponds to a Windows group
> System.Security.Principal namespace provides functions to test role
membership of authenticated user
> e.g. Windows authentication with Web service
if User.IsInRole("Manager") {
// Perform operation
} else {
throw new SecurityException("Invalid role");
}
> No way to separate security code from application logic
> .NET does not provide declarative security
Custom Role-Based
Security
 Custom mechanisms possible
> Based on database of user/role information
> Needs
- database lookup to determine user identity and roles with every request or
- single lookup with ticketing system
 Simple, maintainable solution uses
> Stored database procedure to retrieve permissions for a user
> Private method in remote component which checks permissions using this stored procedure
Example: Custom Role-Based Security
 Stored Procedure
CREATE PROCEDURE CheckPermission
(
@UserName varchar(25),
@Permission varchar(25)
)
AS
SELECT MIN (Allowed) FROM RolesPermissions
INNER JOIN Permissions ON Permissions.ID = PermissionID
INNER JOIN Roles ON Roles.ID = RoleID
INNER JOIN UsersRoles ON Roles.ID = Roles.ID
INNER JOIN Users ON Users.ID = UsersRoles.UserID
WHERE Users.UserName = @UserName AND
Permissions.Name = @Permission
 Remote component private method invokes this procedure, passing
user name and required permission
 Procedure could be modified to integrate authentication if password
supplied
Ticketing Systems
 Checking user authentication on each request is scalability bottleneck
 Ticketing system
> Eliminates authentication on each call
> Performs user authentication once at start of session; if successful, issues ticket –
unique identifier for the user
> Subsequent calls only submit ticket
> Ticket validated to perform user authentication
 Ticket systems have several benefits
> Drastically improves performance if tickets cached in memory
> Limits security breaches to single user session – account information not
compromised
> Allows effective use of secure transports such as SSL
- Encrypted communication used for login
- Encryption may not be necessary to subsequent calls
Submitting Tickets
 Ticket needs to be submitted on each request
 Arranging automatic ticket submission eliminates messy

‘plumbing code’ and simplifies development
With XML Web services this can be implemented by
> defining custom SOAP header which encapsulates ticket
> custom header used on each method call; ticket is passed automatically on
each call
Encryption
 Authentication & authorization do not prevent disclosure of sensitive
data
 Encryption required to protect data sent across the network
> By default, some technologies (e.g. Web services) send data in plain text and are
NOT secure
 Two approaches to encryption
> Use Secure Socket Layer (SSL) to provide fully encrypted network communications
- Gives industrial strength protection, but can be slow
- Not considered further here
> Selectively encrypt data using available cryptography mechanisms e.g. classes in
the .NET Framework System.Securuty.Cryptography namespace
- More work for the developer but potential performance improvements
Cryptographic Algorithms
 Two distinct forms of cryptographic algorithm exist - both rely on strength (i.e.

length) of key not secrecy of algorithms
Symmetric encryption algorithms
> Single key used to encrypt and decrypt information
> Secret key technique; key known only to communicating parties
> Fast but easily compromised as key value often has to be transmitted between client and
server
 Asymmetric encryption algorithms
>
>
>
>
Uses public-private key pair; public key is publicly available
Information encrypted using one of the keys can only be decrypted by the matching key
Based on complex mathematical operations which are slow to solve
Better than symmetric encryption but hundreds of times slower
 Hybrid approach
> Asymmetric encryption used to distribute random key; subsequent interactions use symmetric
encryption with this key
> Better performance than fully asymmetric operation
> More secure than fully symmetric operation
Selective Symmetric Encryption
 After user session authenticated, use secret key encryption
> Reduces processing time and message size
> Random symmetric key generated and asymmetrically encrypted during
transmission
 Symmetric encryption uses initialization vector
> Random series of bytes added to session
 Client typically uses
> Same secret key for all sessions
> Different initialization vector for each session
> Server needs to store client key/vector information
- Should be stored decrypted before storing in memory
- Should be encrypted if placed in persistent store
Implementing Custom Encryption
 Custom encryption can be automatically added to
all communications via
> Custom SOAP extension for XML Web service
 Custom encryption is often not as strong as SSL
encryption due to lack of
> Identity verification
- SSL uses digital certificates to verify identity
> Message authentication
- SSL adds keyed hash code to every message to detect message
tampering
.NET Code Access
Security
 Do not overlook the Code Access Security mechanism of .NET
> Distinct from Windows security and similar in operation to Java notion of protected
“sandbox”, but more dynamic
> Code can request permissions it requires
> CLR gathers evidence about assemblies
- Where it was loaded from, strong name, publisher certificate, etc
> Administrator can define security policy files at enterprise, machine and user level
- Policy sets allowed permissions based on evidence
> Permissions granted to code based on evidence gathered by CLR and policy
definitions
> Certain actions trigger security checks
- CLR performs stack walk to verify that all callers have required security
permissions to perform the action
- Prevents malicious code from tricking trusted code to do something on its
behalf
Summary
 In this session we have briefly considered
security in distributed applications
> Authentication and authorization
> Encryption
> .NET support for security
Reading and Resources
Reading


Matthew MacDonald, Microsoft .NET Distributed Applications: Integrating
XML Web services and .NET Remoting, Microsoft Press, 2003
Chapter 13, pp 421 – 475
Michael Howard & David LeBlanc, Writing Secure Code, 2nd Edition, Microsoft
Press, 2003
Resources

Microsoft Patterns and Practices
>
>
Improving Web Application Security: Threats and Countermeasures ,
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/ThreatCounter.asp
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure
Communication, http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnnetsec/html/secnetlpMSDN.asp?frame=true