1. .NET Mobile Application Development Security in Mobile and Distributed Applications

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

3. 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?

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

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

6. Example: Windows Authentication  Windows OS offers authentication and authorization facilities to the developer in (un)managed code >Support for Windows authentication is automatic with XML Web services 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; }

7. 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 >Custom credentials ­Can retrieve credentials from user via User Interface  Proxy automatically passes credentials to server SomeWebService proxy = new SomeWebService(); proxy.Credentials = System.Net.CredentialCache.DefaultCredentials; SomeWebService proxy = new SomeWebService(); proxy.Credentials = System.Net.NetworkCredential("name", "password");

8. 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 >No way to separate security code from application logic >.NET does not provide declarative security if User.IsInRole("Manager") { // Perform operation } else { throw new SecurityException("Invalid role"); }

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

10. Example: Custom Role-Based Security  Stored Procedure  Remote component private method invokes this procedure, passing user name and required permission  Procedure could be modified to integrate authentication if password supplied 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

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

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

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

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

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

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

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

18.  In this session we have briefly considered security in distributed applications >Authentication and authorization >Encryption >.NET support for security Summary

19. 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, 2 nd 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/en- us/dnnetsec/html/ThreatCounter.asp http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnnetsec/html/ThreatCounter.asp >Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication, http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnnetsec/html/secnetlpMSDN.asp?frame=truehttp://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnnetsec/html/secnetlpMSDN.asp?frame=true