PERVASIVE WEB ARCHITECTURES

AND WEB-DRIVEN
APPLICATION SYSTEMS

Dr. Rahul Banerjee

Computer Science & Information Systems Group
Birla Institute of Technology & Science, Pilani, India
Email: rahul@bits-pilani.ac.in /
Rahul.Banerjee.CSE@Gmail.com
Home: http://www.bits-pilani.ac.in/~rahul/
INTERACTION POINTS

 What is a Pervasive Web Architecture?

 Do the phrases „Pervasive Computing Systems‟
and „Pervasive Web‟ mean the same thing?
 Elements of a Pervasive Web Architecture

 What should you know to design applications

involving pervasive web-applications?
 How do you glue the pieces you have learnt so far
together?
 Tutorial problems on Pervasive Web Application
Design and Implementation
 Discussions and Summarization

 Conclusion
ELEMENTS OF PERVASIVE WEB
 Pervasive Computing Infrastructure involving:
 Internetwork of computing nodes (local / global: private
/ public or a combination)
 HTTP support enabled atop the Internetwork-in-
question with w3c recommendations in place
 Support for the transparency in spite of heterogeneity
of devices, platforms, languages, services
 Provision for Web Service Description, Web Service
Deployment, Web Service Publication, Web Service
Discovery, Web Service Access / Usage, Web Service
Monitoring / Security
 Applications (client, middleware, server side) which
could exploit the above referred provisions on respective
devices / device clusters.
ENABLING WEB-BASED APPLICATIONS FOR
PERVASIVE COMPUTING DEVICES
 Goal: Efficient transformation of input formats to
required output format for delivery and use by pervasive
computing devices OR dynamically generating data in
required format
 The respective mechanisms used to accomplish the task:
„Transcoding‟ and „Device-specific Content Generation‟
 Example: HTML to WML transcoding
 Best suited to structured documents written in mark-up
languages like XML, XHTML etc.
 Involves post-processing of Server-generated web-based
content
 Transcoding can happen at: Application Servers (full or
selective), Application Proxies (full) <former is a better
choice in most cases>
 In many cases, Transcoders come with their own sets of
APIs.
MERITS AND DEMERITS OF TRANSCODING IN
THE APPLICATION SERVER VERSUS
APPLICATION PROXY

 Transcoding at the Application Server has the

advantage that it allows SSL/ TLS support,
selective transformation of content as per need
and user-level transparency
 Transcoding at the Application Proxy takes
away all these advantages but allows ease of
deploying transcoding over just any Webserver,
without necessarily being dependent on the
Application Server-specific implementation-
dependent restrictions.
TRANSCODING VERSUS DEVICE-
SPECIFIC CONTENT GENERATION

 The latter (DSCG) suits freshly developed

applications
 DSCG is also preferable when minimal
access is available to back-end system
services
 It provides better performance
 It is more scalable than Transcoding
 Allows optimization specific to devices
 Costs more
Provision for Web Service Description, Web
Service Deployment, Web Service Publication,
Web Service Discovery, Web Service Access /
Usage, Web Service Monitoring / Security
 Step-1: Web Service Requirement Identification
 Step-2: Web Service Description
 Choice of suitable web service description language
 Identification of required protocols that would allow its use
 Step-3: Web Service Deployment
 Choice of suitable number of tiers and deployment scheme
 Placement, configuration and activation of service elements
 Step-4: Web Service Publication
 Step-5: Web Service Discovery

 Step-6: Web Service Access / Use

NOTE: Some of the duly marked slides have been prepared with
respective input from BITS, MIT Project Oxygen, HP CoolTown
Project, VirginiaTech, UIUC, ETH-Zuich, MSR, UoW, CMU,
IETF, ITU, Sun, W3C, KU, CU, LU, IEEE PC.

Use of copyrighted material from these and other

sources in the following slides is meant for pure
academic reference herein is thankfully acknowledged.
<Not meant for re-distribution!>
Step-1: Web Service Requirement
Identification
 What do we need to know before we begin?

 How do we separate required and desirable (value-

added) features?
Step-2: Web Service Description
 Web Service Description
 Choice of suitable web service description language

 Identification of required protocols that would allow its use

Step-3: Web Service Deployment

 Web Service Deployment

 Choice of suitable number of tiers and deployment scheme

 Placement, configuration and activation of service elements

Step-4: Web Service Publication
 Web Service Publication Strategies

 Web Service Publication Mechanisms

 Web Service Publication Practices (BCP)

Step-5: Web Service Discovery
 Web Service Discovery Process

 Mechanisms for Discovery of Web Services

 Best Current Practices for Web Service Discovery

Step-6: Web Service Access / Use
 Web Service Access / Use: Common Methods

 Issues associated with Web Service Access / Use

Web Service Monitoring & Security
 Web Service Monitoring

 Web Service Security

 WHAT IS A WEB SERVICE?

 A Web Service is simply a service available via the Web

 Service can be implemented in any language.

 Problems with Web Services:

 It is not practical to automatically find web services

for your needs
 There is no built-in mechanism for payment for use of
a web service
 There is no built-in security control
 When a web service changes (e.g., adds a parameter
to its method), the program using it breaks
THE SOAP
 SOAP stands for "Simple Object Access
Protocol"
 Used for "Remote Procedure Calls", similar to:
 IIOP (for Corba), ORPC (for DCOM), RMI (for Java)
 Difference:SOAP is text-based (actually XML),
not binary. Firewall Friendly
 Difference:
Language independent, can call a
program in any language
 Difference:
Uses standard port, since uses
standard protocols
SOAP: RPC & DOC

 SOAP is simply a standard for sending messages (think

of it as an envelope)
 We can send two types of messages using SOAP:
 RPC: Remote Procedure Call, a request to call a method
 DOC: A document (this is used for more complex client -
server communication)
THE SOAP WAY …
 AN ACTUAL SOAP REQUEST LOOKS LIKE …

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header> </SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
AND, AN ACTUAL SOAP RESPONSE LOOKS LIKE …
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">
Hello John, How are you doing?
</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP HEADER SECTION

 The SOAP Header can contain information that describes the

SOAP request. Example:
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI"
SOAP-ENV:mustUnderstand="1">5
</t:Transaction>
</SOAP-ENV:Header>
 Here, 5 is the transaction ID of which this method is a part.
 SOAP envelope's mustUnderstand attribute is set to 1, which means
that the server must either understand and honor the transaction
request or must fail to process the message.
SOAP RESPONSE ON ERROR

 There may be many errors in processing a SOAP

request
 Error in Running Method:
 e.g., the "Hello Server" does not allow anyone to say hello on
Tuesday
 Error in Processing SOAP Headers:
 e.g., Problem running method as part of a transaction
THE MAIN PLAYERS IN SOAP

 There are three components that take part in a SOAP

application:
 Client Application: A program that sends a SOAP request.
Wants to use a service.
 SOAP Processor: A program that can receive SOAP requests
and act accordingly (e.g., call an method of the Application
Server)
 Application Server: A program that supplies the Web service
 APPLICATION SERVER: SOME SIMPLE TIPS

 The application server providing any Web Service does

not need anything special.

 In fact, your application server need not know that it is being

used for providing a Web Service!!
 A BIT ON THE CLIENT APPLICATION

 The SOAP client needs to generate a SOAP request

 When using Java, you shall need the following packages

in your CLASSPATH to compile:
 soap.jar
 mail.jar
 activation.jar
 TIPS ON TOMCAT / SERVLET & SOAP
PROCESSOR SCENARIO
 Your Tomcat web server needs a web application that is
a SOAP Processor
 Put soap.war in your <tomcat_home>/webapps directory
 To actually run the SOAP Processor, it needs the
soap.jar, mail.jar, activation.jar files in its classpath
 Easiest way to get the files in its classpath: Add them to
the directory <tomcat_home>/lib
 CREATING THE APPLICATION SERVER
package hello;
public class HelloServer {
public String sayHelloTo(String name) {
return "Hello " + name +
", How are you doing?";
}
}

•Note: Put application in a package. Create a jar file from the package and
put the package in <tomcat_home>/lib, so that it will be in Tomcat's
classpath
 DEPLOYING THE WEB SERVICE

 The SOAP Processor must be told about your application.

This is called "deploying"

 Deployment is a two-step process:

 Create a deployment descriptor
 Call the java command that deploys the web application
 DEPLOYMENT DESCRIPTOR
<isd:service
xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:helloApp">
<isd:provider type="java"
scope="application"
methods="sayHelloTo">
<isd:java class="hello.HelloServer"/> The scope of the
</isd:provider> Object used to
fulfill the SOAP
<isd:faultListener> Request.
org.apache.soap.server.DOMFaultListenerApplication
means that all
</isd:faultListener> SOAP requests
</isd:service> will be sent to the
same object.
 DEPLOYMENT DESCRIPTOR
<isd:service
xmlns:isd="http://xml.apache.org/xml-soap/deployment"
id="urn:helloApp">
<isd:provider type="java"
scope="application"
methods="sayHelloTo">
<isd:java class="hello.HelloServer"/>
</isd:provider>
<isd:faultListener>
org.apache.soap.server.DOMFaultListener
</isd:faultListener>
</isd:service>
 SCOPE OF WEB SERVICE

 page: The service instance is available until a response

is sent back or the request is forwarded to another
page
 request: The service instance is available for the
duration of the request, regardless of forwarding
 session: The service instance is available for the entire
session
 application: The same service instance is used to
serve all invocations
 Which of these scope values require us to think
about synchronizing access to data members and
methods?
COMPLETING THE DEPLOYMENT

 Save the deployment descriptor in a file, e.g.,

HelloDescriptor.xml
 Run the command:
java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter deploy
HelloDescriptor.xml
where <host> and <port> are those of Tomcat

 Note that Tomcat must be running for this to work

 You can get a list of all deployed web services using the
command
java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter list
 UNDEPLOYING A SERVICE

 You can undeploy a web service, so that it is no longer

recognized by the SOAP Processor using the command
java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter undeploy
urn:helloApp

 Note that the last argument is the URI of the web service
to be removed
WHAT MUST THE CLIENT DO: A SUMMARY NOTE

 Create the SOAP-RPC call

 Set up any type mappings for custom parameters
 Set the URI of the SOAP service to use
 Specify the method to invoke
 Specify the encoding to use
 Add any parameters to the call
 Connect to the SOAP service
 Receive and interpret a response
NOTE ON PARAMETERS
 It must be possible to "serialize" the parameters that
the method invoked receives and returns.

 The following have default

serialization/deserialization:
 primitive types: int, long, double, etc.
 primitive Objects: Integer, Long, Double, String, etc.
 complex Objects: Vector, Enumeration, Hashtable, arrays
 easy to use JavaBeans
CREATING THE SERVER

 When the application server is a script, the script is

actually put in the deployment descriptor

 Need the jar files bsf.jar and js.jar

 Put them in your <tomcat_home>/lib directory

UDDI - UNIVERSAL DESCRIPTION,
DISCOVERY AND INTEGRATION SERVICE

UDDI is a standard for describing

and finding web services
UDDI BUSINESS REGISTRY (UBR),
PUBLIC CLOUD
 Nodes contain all UDDI information

 Nodes are synchronized, so they retain the same data

 You can query any node

 You can add UDDI to a node, and it will be replicated to

all others
INTERACTING WITH THE UDDI

 UDDI is itself a web service!!!

 Interaction is via SOAP messages
 The JAXR package defines a standard way to interact
with registries (can work with other types of registries
too, e.g., ebXML)

 Two types of interaction:

 Inquiry: Does not need authentification
 Publish: Needs authentification
WSDL - WEB SERVICES DESCRIPTION
LANGUAGE
DESCRIBING A WEB SERVICE

 SOAP is just one standard to access a web service,

there are many others (XML-RPC)
 Need a standard way to describe a Web Service:
 the methods available
 their parameters
 etc.
 WSDL is a standard for describing web services using
XML
 UPNP SERVICES

 Description is stored as XML file

 Control via SOAP messages: SOAP developed for
web service
 Most every language/platform has SOAP/XML
libraries
 Event notification with XML in General Event
Notification Architecture
 Presentation URL can be supplied by device
THE OSGI

 OSGiis open, standards-based, language-

neutral and OS-neutral

 Consists of framework in which bundles of

services that register with a registry can run

 Runsatop the Java 2 Runtime Environment

(J2RE)
OSGI SERVICE SPECIFICATIONS

 Logging service  User administration

 Web server service
 Device access  Permission

 Configuration service
administration
service
 Preferences service
 Package
administration
service
 CLIENT AUTHENTICATION OVER THE
INTERNETWORKS
 There exist four possibilities:
 No Authentication
 Basic Authentication
 Moderate Authentication
 Advanced Authentication

 Basic Authentication: It may be provided as an extension to

the HTTP 1.1 (HHTP: RFC 2616, Extn.: RFC 2617)
 Moderate Authentication: Digest Access Authentication using
Challenge-Response technique
 Advanced Authentication: There are two choices, depending
upon the requirements:
 Kerberos-based Authentication (K-5: RFC 1510)
 Public-Key Cryptography-based Authentication (SSL: RFC
2246, TLS: RFC 2818)
BASIC AUTHENTICATION …

 Client may use it to authenticate itself to either the Origin

Server or an intermediate Proxy Server.

 In this basic scheme, if an unauthorized access attempt is

made by a client, server / proxy sends it back an Error
Code: 401 / 407: Unauthorized Access Error

 However, server / proxy may ask / challenge the requesting

client to supply / respond to one or more pieces of
information and if the client sends the correct piece (s) in
its response the access to restricted resource is granted.
BASIC AUTHENTICATION …

 Inthis scheme, user‟s ID and his/her password

are transmitted using base64-ended plaintext.

 This
clearly is as insecure as the default
Telnet authentication scheme.

 Moderate and Advanced schemes of

authorization attempt to tackle this issue by
offering cryptographic measures.
MODERATE AUTHORIZATION USING
DIGEST ACCESS
 In this case, a client requesting a restricted service
receives a nonce-challenge from the server and is expected
to generate a message digest using this nonce containing
the user Id, password, numeric value of the received nonce,
the requested HTTP method and the URI.

 This digest is then transmitted over the insecure network

to the server who upon receipt, knowing the nonce and
algorithm itself, verifies the response and if found to be
correct provides the requested access to service / resource.
ADVANCED AUTHENTICATION USING SSL / TLS

 In this case, as discussed earlier, if a client requests

an access to a restricted service, the server
generates a random secret / challenge to the client.

 Client is expected to respond by signing the sent

challenge by using its Private Key and transmit this
signed response along with its digital certificate.

 Upon receipt, the server verifies the authenticity of

the certificate, extracts client‟s public-key from it
and using this verifies the client‟s signature.

 If the process succeeds, the client is granted access

to the requested service / resource.
APPLICATIONS ON RESPECTIVE DEVICES /
DEVICE CLUSTERS
 Client-side Issues,

 Middleware-specific Issues

 Server-side Issues
ROLE OF NETWORK SECURITY IN
PERVASIVE COMPUTING ENVIRONMENTS
INTERACTION POINTS
 Brief introduction to Network and internetwork
Security Principles
 Various forms and mechanisms of security

 Influence of Network Security on Pervasive

Computing Systems
 Discussion
NETWORKS, INTERNETWORKS &
SECURITY
 Network
 A Computer Network is an interconnected group of autonomous
computing nodes which:
 Use a well-defined, mutually-agreed set of rules and conventions
known as Protocols,
 Interact with one-another meaningfully;
 Allow resource-sharing preferably in a predictable and controllable
manner.
 Internetwork
 A network of two or more networks is called an Internetwork
 Participating networks in an Internetwork may be interconnected
for restricted or unrestricted resource sharing
 Security
 Security is often viewed as the need to protect one or more aspects
of network‟s operation and permitted use (access, behaviour,
performance, privacy and confidentiality included),
 Security requirements may be Local or Global in their scope,
depending upon the network‟s or internetwork‟s purpose of design
and Banerjee,
(c) Rahul deployment. 54
BITS, Pilani (India)
 Criteria for Evaluating Security Solutions

 Ability to meet the specified needs / requirements

 Effectiveness of Approach Across Networks

 Computing Resources Needed vis-à-vis the value of

the protection offered

 Quality and Scalability

 Availability of Monitoring mechanisms

 Adaptability and Flexibility

 Practicability from Sociological / Political perspective

 Economic considerations & Sustainability

(c) Rahul Banerjee, BITS,

Pilani (India)
55
CLASSIFICATION OF SECURITY PROBLEMS:
ACCESS BREACHES IN INTERNETWORKS
(S/W & H/W)
 Intentional / Non-Intentional Access
Breaches
 Origin-based Access Breaches
 Centralized / Distributed Access
Breaches
 Service Blocking / Overwhelming /
Redirection /Abuse / Modification /
Termination-based Access Breaches
 Periodic / Aperiodic Application-Data /
Control-Data Access Breaches
 Event-based Access Breaches
 Storage-based Access Breaches

(c) Rahul Banerjee,

56
BITS, Pilani (India)
OF SECURITY ATTACKS, SECURITY THREATS,
SECURITY MECHANISMS AND SECURITY
SERVICES
 Security Attack => compromises the
information-system security
 Security Threat => has potential for security
violation
 Security Mechanism => detects / locates /
identifies / prevents / recovers from “security
attacks”
 Security Service => enhances security, makes
use of the security mechanisms

(c) Rahul Banerjee,

57
BITS, Pilani (India)
 ACTIVE VERSUS PASSIVE ATTACKS
 Active attacks involve active attempts on security
leading to modification, redirection, blockage or
destruction of data, devices or links.
 Examples:
Replay attacks


 Masquerade attacks

 Modification / corruption of data or access

control bits
 Denial-of Service attacks

 Passive attacks involve simply getting access to

link or device and consequently data.

(c) Rahul Banerjee,

58
BITS, Pilani (India)
A TYPICAL INTERNETWORK MODEL OF
SECURITY
 Parties involved:
 Sender
 Receiver
 Interceptor (Passive / Active)
 Devices involved:
 Transmitter
 Receiver
 Encoder
 Decoder
 Links involved:
 Data and Control signal transmission links

(c) Rahul Banerjee,

59
BITS, Pilani (India)
IDENTIFICATION OF SOURCES OF
SECURITY PROBLEMS
 Importance of Identification of sources
 Strategic importance for planning, preventing and /
or countering
 Importance with respect to Sensitivity-analysis
and Economic-impact-analysis and pro-active
protection
 Possible Approaches for Analysis
 Monitoring-based approaches
 Log-based
 Agent-based

 Non-monitoring approaches
 Model-based
 Experimental Replication-based

(c) Rahul Banerjee,

60
BITS, Pilani (India)
ROLE OF CRYPTOGRAPHY, OS &
CONFIGURATION
 Role of Cryptography
 Secret-key cryptography
 Public-key cryptography
 Role of Operating Systems
 Built-in OS Security at the Kernel-level
 Support for Cryptographic APIs
 Network Protocol Stack implementation
decision-based security
 Role of Configuration in Security
 Network configuration
 OS configuration
 Application configuration
 Security System configuration
(c) Rahul Banerjee,
61
BITS, Pilani (India)
 ON THE INTERNETWORK
CRYPTOGRAPHY
 Internetwork Cryptography aims to handle
 internetwork-specific or network-specific issues
and
 problems involving authentication, integrity and
secrecy / confidentiality / privacy.
 Cryptography can exist with or without
networks but Internetwork / Network
Cryptography specifically addresses the
Internetwork / Network needs /
requirements and is thus a subset of general
cryptography.

(c) Rahul Banerjee,

62
BITS, Pilani (India)
 SYMMETRIC-KEY CRYPTOGRAPHY

 Symmetric-Key cryptography is called so since in

this class of cryptographic algorithms, encryption as
well as decryption processes are performed using the
same (i.e. symmetric) key.
 The algorithms / schemes / programs that use this
paradigm are often termed as Symmetric-Key
Ciphers / Private-Key Ciphers / Secret-Key Ciphers /
Conventional Ciphers etc.
 In such cases, Plaintext, Encryption-Decryption
Algorithm, Key and Ciphertext form four basic
components of the Symmetric Cipher Model.
 Such schemes should exhibit:
 Security of Key Distribution to the legal recipients)
 Adequate strength of Encryption
(c) Rahul Banerjee,
63
BITS, Pilani (India)
CHARACTERIZING THE SYMMETRIC KEY
CIPHERS
 This is often done by:
 Choice of key-space

 Key-derivation / identification within the key-space

 Number of cycles involved in encryption /

decryption process
 Choice of operations (or choice of type of operators)
that are used in the process of encryption /
decryption
 Number of internal algorithms that form the final
scheme of enciphering / deciphering
 Role, if any, of the compression algorithms /
schemes in adding the security value

(c) Rahul Banerjee,

64
BITS, Pilani (India)
 SOME MORE BASICS
 Any cryptographic scheme is safe if and only if it is
unbreakable in reasonable time using feasible resources
in spite of the intruder‟s being aware of:
 Encryption and decryption algorithm

 Size of the key

 Kerckhoff’s Principle: Security of conventional

encryption depends only upon the Secrecy of the
Key, and not on the Secrecy of the Algorithm.
 Strength of the algorithm and the size of key remain
two important factors in Cryptography.
 Unconditionally secure and Computationally secure
schemes of cryptography do exist; but in practice
involving computers, only the latter is popular.
(c) Rahul Banerjee,
65
BITS, Pilani (India)
CONVENTIONAL (SECRET-KEY)
CRYPTOGRAPHY

Requirements for secure deployment of

conventional cryptography:
 Availability of a strong Encryption Algorithm
 Secure distribution of the Secret Key to the intended
recipients

Kerckhoff’s Principle remains a guiding line for the

research on conventional cryptography and its real-life
use in internetworks.

Terms like Conventional / Private-Key / Secret-Key /

Symmetric-Key cryptography are interchangeably used
in literature.
(c) Rahul Banerjee,
66
BITS, Pilani (India)
UNCONDITIONALLY SECURE VERSUS
COMPUTATIONALLY SECURE ENCRYPTION SCHEMES

 Unconditionally Secure Encryption schemes:

 Here, the generated Ciphertext simply does not have
adequate information to allow discovery of the unique
plaintext irrespective of the amount of Ciphertext
available (as well as irrespective of the computational
resource available) to the attacker.
 Computationally Secure Encryption schemes
 Here, the cost of deciphering exceeds the value of
enciphered information
 Time needed to decipher exceeds the lifetime of the
enciphered information
(c) Rahul Banerjee,
67
BITS, Pilani (India)
 DIGITAL SIGNATURES
 A Digitally-signed Communication is a message that
has been processed by a computer in such a manner
that ties the message to the individual that signed
the message.
 Criteria for Digital Signatures Technology:
 An acceptable technology must be capable of
creating signatures that conform to
requirements:
 It is unique to the person using it;

 It is capable of verification;

 It is under the sole control of the person

using it;
 It is linked to data in such a manner
that if the data are changed, the digital
(c) Rahul Banerjee,
signature is invalidated.
68
The technology known as Public Key
BITS,Pilani (India)
 SIGNATURE DYNAMICS

 The Signature Dynamics Technology:

 It is an acceptable technology for use by
public entities that uses as the means the
metrics of the shapes, speeds and/or other
distinguishing features of a signature as
the person writes it by hand.
 It involves binding the measurements to
a message through the use of cryptographic
techniques.
 Signature Digest is the resulting bit-string
produced when a signature is tied to a
document using Signature Dynamics.
(c) Rahul Banerjee,
69
BITS, Pilani (India)
 DIGITAL CERTIFICATES

 Digital Certificate: It refers to a

computer-based record which:
 identifies the certification authority
issuing it;
 names or identifies its subscriber;
 contains the subscriber's public key;
and
 is digitally signed by the certification
authority issuing or amending it &
 conforms to widely-used standards.
(c) Rahul Banerjee,
70
BITS, Pilani (India)
RELATED TERMS:

 Certification Authority: This refers to an

entity that issues a certificate, or in the case
of certain certification processes, certifies
amendments to an existing certificate.

 Key Pair: This refers to a private key and its

corresponding public key in an asymmetric
cryptosystem. The keys have the property
that the public key can verify a digital
signature that the private key creates.

(c) Rahul Banerjee,

71
BITS, Pilani (India)
A FEW MORE POINTS ON DIGITAL
CERTIFICATES
 One of the simplest ways to describe the function of a
Digital Certificate is to treat it as a means to verify the
genuineness of the Public-Key.
 Just as the individuals / groups are normally assigned
Digital Signatures, the corporate merchants and E-
Commerce / I-Commerce Gateways are issued Digital
Certificates for proving their authenticity to others.
 Certificate Expiry: Most of the certificates have their
period of legal validity as marked by the issuing entity
/ authority, after which it is considered as invalid or
expired.
 Certificate Revocation: If the Certificate is found to be
compromised, it may be explicitly revoked by the
Certificate Authority (CA) and included in the
subsequently published Certificate Revocation List.
 Certificate Validation: It refers to the verification of
the Certificate Chain.
(c) Rahul Banerjee,
72
BITS, Pilani (India)
WHO ARE THE COMMON CERTIFICATE
AUTHORITIES?
 As per the Secure Electronic
Transactions (SET) standard, the
following CAs may exist:
1. The Root Certificate Authority (RCA)
2. The Brand Certificate Authority (BCA)
3. The Geo-Political Certificate Authority
(GCA) <optional>
4. The Merchant Certificate Authority (MCA)
5. The Payment Gateway Certificate
Authority (PGCA)
6. The Cardholder Certificate Authority
(CCA)
 Certificate Categories:
1. Merchant Certificates
2. Cardholder Certificates
(c) Rahul Banerjee,
73
BITS, Pilani (India)
 THE HIERARCHICAL CA ARCHITECTURE

The Root Certificate Authority (RCA)

The Brand Certificate Authority
(BCA)
The Geo-Political Certificate
Authority (GCA) <optional>

MCA PGCA CCA

Merchant Payment Cardholder
Certificates Gateway Certificates
(c) Rahul Banerjee,
74
BITS, Pilani (India)
WHO ISSUES AND SIGNS THE CERTIFICATES?

A Certificate Authority is a Trusted entity

that issues, monitors, revokes, modifies
and cancels digital certificates for a
subscribers holding / requiring certificates.
 A digital certificate is signed with CA‟s
private key.
 In principle, certificates can be of several
types including Institutional Authority
Certificates and Web Server Certificates.

(c) Rahul Banerjee,

75
BITS, Pilani (India)
 STEPS INVOLVED
1. A pair of Private and Public keys is created by
the Requester.
2. Requester generates and encrypts a Certificate
Request using its private key and sends the
certificate request to your chosen CA .
3. CA initiates and completes a process to verify
the correctness of the information supplied by
the Requester.
4. The certificate for the Requester (who hereafter
becomes a Subscriber) is signed by a device that
holds the private key of the CA.
5. The certificate is sent to the Subscriber.
6. A copy of the issued Certificate is kept in
certificate repository / directory (so that using
(c)LDAP etc.
Rahul Banerjee, Certificates could be retrieved).
76
BITS, Pilani (India)
 CERTIFICATE REVOCATION

 Certificate revocation: Canceling a certificate

before than its originally scheduled validity
period.
 Certificate Revocation Lists (CRL)
A CRL is a time-stamped list of revoked
certificates
 Online Certificate Status Protocol is used for
online verification.

(c) Rahul Banerjee,

77
BITS, Pilani (India)
TRUSTED VERSUS UNTRUSTED
NETWORKS
 My Network (PAN/LAN)
 Fully Trusted
 Partly Trusted
 Our Network (LAN/MAN/WAN/WAI)
 Fully Trusted
 Partly Trusted
 Unsure
 OtherNetworks
(LAN/MAN/WAN/WAI)
 Partly Trusted
 Untrusted
(c) Rahul Banerjee,
78
BITS, Pilani Unsure
 (India)
 THE NETWORK PERIMETER
A Network / Internetwork Perimeter is a
secure boundary of a network that may
include some or all of the following:
 Firewalls
 Routers
 IDS
 VPN mechanisms
 DMZ
 Screened subnets
 DMZ is outside the Firewall
 Screened subnet is an isolated sub-
network connected to a dedicated
(c) Rahulfirewall
Banerjee, interface 79
BITS, Pilani (India)
 INTRUSION DETECTION SYSTEM
 Intrusion Detection System (IDS) is
a system that
 comprises of mechanisms / devices
involving one or more Intrusion
Detection Sensors (traffic monitoring
devices / mechanisms) placed at
security-wise strategic locations; and,
 Has been designed to detect any known
or likely intrusion into the protected
network.
 Types of IDS:
 Network-based IDS (NIDS) : Subnet-
resident
 Host-based IDS (HIDS) : Host resident
 Sensor reporting may involve several
(c) Rahul forms
Banerjee, like logs, database updates,
80
BITS, Pilani (India)
 INTERNETWORK FIREWALL

 Firewall is an internetwork security

device that
 serves on the only access route that connects
the internal network / internetwork (i.e. the
segment to be protected) to the external
network (s) / internetwork (s); and,
 decides about physically allowing / denying
entry / exit to / from the protected segment
using a set of policies (often manifested in
terms of rules) is called a Firewall.
A Firewall may be implemented in
hardware / software / firmware or a
combination of these.
(c) Rahul Banerjee,
81
BITS, Pilani (India)
 CHARACTERISTICS OF INTERNET
FIREWALLS
 Characteristically, an Internet Firewall exhibits security
measures and internetwork-control-mechanisms related
to but not necessarily limited to:
 Internet services as separated from the intranet services
 Service-based directional traffic
 User-specific / Class-specific / Group-specific service access
 Service-usage / deployment-behaviour
 Origin-specific / Destination-specific service / traffic /
monitoring / QoS-security bindings
 Relaying / blocking / redirection of encapsulated and / or
encrypted traffic
 A common assumption (though debatable) made is that
the Firewall itself is incorruptible / impenetrable
 A firewall works under the assumption that it is solely
responsible for blockade / allowance of any traffic between
two or more than two networks / internetworks separated
by it.
(c) Rahul Banerjee,
82
BITS, Pilani (India)
 WHAT DOES A FIREWALL DO?
As part of an Internetwork Security System, a
firewall:
 Allows defining exit and entry points for traffic from
and to the internal protected network / intranet
 Offers a set of mechanisms and a set of locations /
points for supervising security-sensitive activities /
events / behaviour
 Provides network-level encapsulation, encryption,
decryption, decapsulation, tunnelling services
 Permits a variable-security facility-zone‟s creation
that may also offer some functionalities not
necessarily related to the security function that is
the primary function of the firewall
 Supports creation and interpretation of structured
logging mechanisms and files for a variety of
purposes.
(c) Rahul Banerjee,
83
BITS, Pilani (India)
 WHAT A FIREWALL DOES NOT DO?

A Firewall is not meant for:

 Virus / Worm / Trojan Horse / Logic bomb detection
 Virus / Worm / Trojan Horse / Logic bomb removal
 Semantic analysis of the application-to-application
messages with certain exceptions
 Protecting a network / internetwork from a trusted
entity (client / server / user) or an internal
authorized user with adequate privileges
 Protecting from power, link or protocol failure
 Monitoring processes at individual workstations /
servers / switches that are of local significance to
that machine or network segment except for certain
explicitly registered classes of processes / systems /
users / patterns
 Guarding against traffic that bypasses the Firewall
itself
(c) Rahul Banerjee,
84
BITS, Pilani (India)
 CONSTITUENTS & TYPES OF A
FIREWALL
 Firewall Constituents: (some of these can serve as firewalls as
well)
 Application-level Gateways and Proxies
 Transport-level / Circuit-level Gateways and Proxies
 Network-level Gateways / Routers
 Packet filters (also known as Static Packet Filtering
Firewalls)
 Bastion Host
 Screened Host
 Types of Firewalls:
 Stateless Firewalls
 Stateful Inspection-based Firewalls
 Perimeter Firewalls
 Screened Host Firewalls
 Intranet Firewalls
 Internet Firewalls
(c) Rahul Banerjee,
85
BITS, Extranet
 Pilani (India) Firewalls
 EXAMPLES OF COMMERCIAL
FIREWALLS

 Static Packet Filtering Firewall

(implemented on a Router):
Example:
Nortel’s Accellar Router
Firewall
 Proxy Firewall:
Example:
Secure Computing’s
Sidewinder Firewall
 Stateful Inspection-based
Firewall:
Example:
(c) Rahul Banerjee,
BITS, Pilani (India)
86
 VIRTUAL PRIVATE NETWORKS
 A Virtual Private Network (VPN) is a mechanism
that allows establishment of a protected session
between two network nodes / services located in / on
two different protected networks / internetworks
separated by unprotected / untrusted / insecure
(often public) networks / channels / infrastructure.
 Example: Nortel’s Contivity, Cisco’s VPN 3000
Concatenator
 Another perspective: SSH, TLS, SSL, IPSec, L2TP,
PPTP are choices providing different types of
security at different layers.
 Although, all of these could be reused in an
appropriately designed VPN mechanism, often the L-
3 and L-2 mechanisms are preferred by many VPN
designers.
 Often, people refer to a VPN as a security device /
mechanism on the perimeter of the protected
(c) Rahulnetwork
Banerjee, / internetwork that allows encrypted
87
sessions.
BITS, Pilani (India)
 ADVANTAGES OF VPNS

 Capability to access remote

network as if there exists a
private channel to that network
 Several security options
available to provide a range of
security
 Adequacy of lower-strength
encryption schemes on certain
occasions
 Cost-effective if well-designed,
well-implemented and well-
configured
(c) Rahul Banerjee,
88
 Can be quickly implemented
BITS, Pilani (India)
 DISADVANTAGES OF VPNS

 Requirement of encryption, decryption,

encapsulation and decapsulation induce a sizeable
processing overhead, packet overhead and storage
overheads and may introduce latency as well as
increase cost of service
 In some cases, if designed ad-hoc, certain network
installations may pose additional challenges in
adding the VPN functionality due to the added
overhead in packet processing.
 Intricate design issues, unless handled carefully,
may actually serve to lower the network
performance without really bring corresponding
increase in the security level of the network.
 Implementation issues include VPN pass through
issues, NAT-specific issues and MTU-size related
(c) Rahulissues
Banerjee,
89
BITS, Pilani (India)
 Defining the Control Zone
•The Control Zone:
•Consider a typical electronically controlled device like a
tape drive, hard disk drive or other gadget that operates in
an unshielded environment. Each such device emits signals
that can be sensed within a zone called Control Zone.
•For security reasons, it is important that:
•No important information about any device operation
leaks out of the target environment
•No external body should be able to make use of
control or data signals related to this device

(c) Rahul Banerjee, BITS,

Pilani (India)
90
 The Concept of Security
Services
•Authentication Service
•Access Control Service
•Availability Service
•Confidentiality Service
•Integrity Service
•Identification: Author, Authorization, Endorsement,
Approval, Access, Concurrence, Licensing, Certification,
Signature, Witness, Validation, Timestamps, Authenticity,
Ownership, Registration, Privacy / Confidentiality /
Secrecy
•Non-Repudiation Service
(c) Rahul Banerjee, BITS,
Pilani (India)
91
GSM NETWORK ARCHITECTURE
PSTN/ISDN

MS MSC 800, 900, 1900

BTS
Um BSC Mhz
A
A-bis Licensed &
expensive
Subscriber model
Started out
Mobility like PSTN,
OMC mgt
VLR
and getting
HLR more complex
AUC Pre-paid,
Voice Traffic
EIR premium
rate SMS

(c) Source: http://choices.cs.uiuc.edu/MobilSec/posted_docs/

 Wireless Application Protocol

WAP SECURITY ARCHITECTURE

(c) Source: http://choices.cs.uiuc.edu/MobilSec/posted_docs/

 BLUETOOTH SECURITY ARCHITECTURE

(c) http://www.cs.hut.fi/Opinnot/Tik-86.174/Bluetooth_Security.pdf
 IEEE 802.11 ARCHITECTURE

(c) Source: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/reskit/prdc_mcc_ardu.asp

MOBILE IP

Foreign Agent (FA)

Home Agent (HA)
charliep@nokia.com

Binding update issue:

● If I change FA how do I tell home agent and previous FA

such that no-one else can spoof that message?

● And in a performant, scalable manner?

● MobileIPv6 has this problem (no FA though, just care-of address)

(c) Source: http://www.iab.org/Workshops/IAB-wireless-workshop/

J2ME

J2ME includes some

security primitives for
code signing and to
support (some)
application security

(c) Source: http://choices.cs.uiuc.edu/MobilSec/posted_docs/ & (c) Sun Microsystems Inc.

COMMON SECURITY ISSUES
 Over the air (OTA) confidentiality
 But don't ignore e.g. Microwave links used after a base
station!
 Data origin authentication/integrity for some data and
some origins
 Bad use of cryptography
 Various types of fraud
 Cloning of hosts
 Re-direction to premium rate
 Authentication of node or user?
SECURITY RELEVANT DIFFERENCES
 GSM's subscription model vs. 802.11's lack of a
subscriber model
 Subtle and different mis-uses of crypto (more later)
 Open or closed node operating systems
 GSM SECURITY
Mobile Station Radio Link GSM Operator
Challenge RAND
SIM
Ki A3 A3
Ki

Signed response (SRES)

SRES SRES
A8 A8
Authentication: are
SRES values equal?
Fn Kc Kc Fn
A5 A5
mi Encrypted Data mi
GSM CRYPTO BREAKS
 Several
researchers have developed breaks
of GSM's use of encryption
 Typically involve some known plaintext and quite
intensive (though do-able) memory and processing
 e.g. Goldberg, Wagner, Green: requires difference in the
plaintext of two GSM frames, which are exactly 2^11 frames
apart (6 seconds) with time complexity of 2^16 dot products
of 114 bit vectors.
 Base stations can also be impersonated
 No authentication of BSC to ME!

(c) Source: http://choices.cs.uiuc.edu/MobilSec/posted_docs/

GSM ATTACK DETAILS

 GSM Encryption uses A5:

 A5/0 – no encryption
 A5/1 - “strong” encryption
 A5/2 - “export” (i.e. designed weak) encryption
 Alluse a 64-bit key generated from the
network's challenge
 Same key bits regardless of algorithm!!!
GSM ATTACK DETAILS (2)
 A5 is a stream cipher
 Applied after error correcting bits are added
 even though the attacker might not know the values of
particular input bits,
 they know that certain groups of them XOR to 0
 taking the same groups of encrypted bits and XORing
them
 reveals the corresponding XOR of the keystream
bits
GSM ATTACK DETAILS (3)
 Numbers:
 A5/2 passive attack (eavesdropping) requires milliseconds
of ciphertext!
 A5/1 ciphertext only attack:
 5 minutes of intercepted frames (doesn't have to
be one call)
 4.4 terabytes of disk

 a lab full of 2003 AD type PCs for a year's worth

of one-time precomputation
 Active attacks: bid down to A5/2
 IEEE 802.11 security

WARDRIVING / BOATING

● Picking up IEEE 802.11

access points as you
cycle/drive/fly/sail past
● Many of these give

(sometimes intentionally)
open access to the Internet

http://www.catalina42.org/war-sail/
802.11 SECURITY OVERVIEW
 Good setup depends on network topology
 There are a few choices
 WEP is broken and IPsec should be used
instead as much as possible (probably in
tunnel mode)
 TLS should then be used wherever sensible above
IPsec (e.g. IMAP over SSL)
 Thensecure applications should be used
where possible
 Probably based on proprietary protocols (which
may make use of standard constructs like PKCS#7)
 WEP ENCAPSULATION
802.11 Hdr Data

Encapsulate Decapsulate

802.11 Hdr IV Data ICV

WEP Encapsulation Summary:

• Encryption Algorithm = RC4
• Per-packet encryption key = 24-bit IV concatenated to a pre-shared key

• WEP allows IV to be reused with any frame

• Data integrity provided by CRC-32 of the plaintext data (the “ICV”)
• Data and ICV are encrypted under the per-packet encryption key
 PROPERTIES OF VERNAM CIPHERS (1)
The WEP encryption algorithm RC4 is a Vernam Cipher:

Pseudo-random
Encryption Key K number
generator

Random byte b

Plaintext data byte Ciphertext data byte

p  c

Decryption works the same way: p = c  b

PROPERTIES OF VERNAM CIPHERS (2)

Thought experiment 1: what happens when p1 and p2 are

encrypted under the same “random” byte b?

c1 = p1  b c2 = p2  b

Then:

c1  c2 = (p1  b)  (p2  b) = p1  p2

Conclusion: it is a very bad idea to encrypt any two bytes of data

using the same byte output by a Vernam Cipher PRNG.
 HOW TO READ WEP ENCRYPTED TRAFFIC (1)
802.11 Hdr IV Data ICV

24 luxurious bits Encrypted under Key +IV using a

Vernam Cipher

•By the Birthday Paradox, probability Pn two packets will share same IV
after n packets is P2 = 1/224 after two frames and Pn = Pn–1 + (n–1)(1–Pn–1)/
224 for n > 2.
• 50% chance of a collision exists already after only 4823 packets!!!

• Pattern recognition can disentangle the XOR-ed recovered plaintext.

• Recovered ICV can tell you when you’ve disentangled plaintext correctly.
• After only a few hours of observation, you can recover all 224 key streams.
HOW TO READ WEP ENCRYPTED TRAFFIC (2)
 Ways to accelerate the process:
– Send spam into the network: no pattern recognition
required!
– Get the victim to send e-mail to you
• The AP creates the plaintext for you!
– Decrypt packets from one Station to another via an
Access Point
• If you know the plaintext on one leg of the journey, you can
recover the key stream immediately on the other
 FIXING WEP
 Protect against ALL known threats:
 IV Collisions
 Weak Keys
 Message Forgery
 Replay
 Two alternatives: Short-term and long-term
 Short-term:
 Temporal Key Integrity Protocol (TKIP)
 Does not require new hardware (but firmware/software)
 Some performance penalty
 Longer term
 Move to AES based primitives with “proper” key
management
THE 802.11X SECURITY SCHEME
 A REASONABLE 802.11 CONFIGURATION

http://csrc.nist.gov/publications/nistpubs/800-48/NIST_SP_800-48.pdf
WLAN TOPOLOGIES
 Sensible network topologies
 Corporate (small WLAN)
 Corporate (widespread WLAN)
 Service provider
 Volunteerism
 Network topology issues
 Network access
 Address allocation (DHCP)
 NAT/private addresses
 Firewall location and rulesets
SOME INTERESTING NETWORKS
 Mobile Ad-hoc networks:
 Idea is that a network emerges from nodes which just
happen to be in the vicinity (AODV)
 Delay tolerant networks
 Sensor networks
 Issues:
 Mainly academic at the moment
 Security not really thought all the way through for these yet
PERVASIVE / UBIQUITOUS COMPUTING
 What if loads and loads of things (doors, TVs,
couches) were nodes on a network?
 Hot topic
 How do you secure these systems?

 TCD and partners SECURE project

 http://secure.dsg.cs.tcd.ie/
CONCLUSIONS (1)
 Thereare a range of different types of mobile
network
 GSM and 802.11 are the interesting ones
 Security hasn't been handled well for these
 Nor was it for the wired Internet for a loooong time!
 There are substantial security problems with
today's deployed mobile networks
 So,overlaying a VPN is probably a good idea
in most cases
 And overlay that with TLS and that with application
security if you can
CONCLUSIONS (2)
 Usersare generally less in control of mobile
networks
 Bandwidth is allocated
 Manufacturer/Operator/Subscriber model differs
from wired Internet
 e.g. Closed operating systems
 Network security is “given” and not easily
fixed/managed
 So, try to gain control of your applications and
try to secure the applications themselves
 Better if wireless technology changes anyway
 Can create a porting headache though
ACKNOWLEDGEMENTS
 Some of these slides have been inspired by / borrowed
from some well-received presentations made in
different parts of the world.
 All inspired / reused slides either carry their
respective „copyright‟ information on them or have
been acknowledged about their sources in a group
just after / before their respective usage herein.
 These slides are being used here purely for
instructional purposes during a live session for the
registered students of the Network Security course
SS ZG 513 and are NOT meant for any kind of reuse,
redistributions etc.
 All slides which carry my „copyright‟ information are
my own.

(c) Rahul Banerjee,

120
BITS, Pilani (India)
ANY QUESTIONS?

Thank you!

(c) Rahul Banerjee,

121
BITS, Pilani (India)
RECOMMENDATIONS FOR
FURTHER READING
 Books

 Bruce Schneier: Applied Cryptography, Wiley

Student Edition, Second Edition, Singapore,
1996.
 Alfred Menezes, Paul van Oorschot, and Scott
Vanstone: Handbook of Applied Cryptography.
CRC Press, NY.
 William Stallings: Cryptography and Network
Security. Fourth Edition. Prentice-Hall,
Englewood Cliffs, 2006. <Recommended
companion>
 C.Kauffman, R.Perlman and M.Spenser: Network
Security, Second Edition, Prentice Hall,
Englewood Cliffs, 2002.
 S.Bellovin and W.Chesvick: Internet Security and
Firewalls, Second Edition, Addison-Wesley,
(c) Rahul Banerjee,
Reading,
BITS, Pilani (India) 1998. 122
THAT‟S ALL FOR TODAY!

 Any questions please?

 Thank you!