Network Security - Module 4

Published on June 2016 | Categories: Documents | Downloads: 50 | Comments: 0 | Views: 351
of 30
Download PDF   Embed   Report

Comments

Content

Not to be published to external person other than students of Rajagiri school of engineering and technology

Module 4
Kerberos Kerberos is the name of a computer network authentication protocol, which allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner. It is also a suite of free software published by Massachusetts Institute of Technology (MIT) that implements this protocol. Its designers aimed primarily at a client-server model, and it provides mutual authentication — both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party. Extensions to Kerberos can provide for the use of public-key cryptography during certain phases of authentication. Protocol: The security of the protocol relies heavily on participants maintaining loosely synchronized time and on short lived assertions of authenticity called Kerberos tickets. What follows is a simplified description of the protocol. The following abbreviations will be used:
• • • •

AS = Authentication Server TGS = Ticket Granting Server SS = Service Server TGT = Ticket Granting Ticket

Briefly, the client authenticates to AS using a long-term shared secret and receives a ticket from the AS. Later the client can use this ticket to get additional tickets for SS without resorting to using the shared secret. These tickets can be used to prove authentication to SS. In more detail: User Client-based Logon Steps:
1. A user enters a username and password on the client machine. 2. The client performs a one-way function (Hash mostly) on the entered password, and this

becomes the secret key of the client. Client Authentication Steps:
1. The client sends a cleartext message to the AS requesting services on behalf of the user.

Sample message: "User XYZ would like to request services". Note: Neither the secret key nor the password is sent to the AS. 2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

Message A: Client/TGS Session Key encrypted using the secret key of the user. Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS. 3. Once the client receives messages A and B, it decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.
o o

Client Service Authorization Steps: 1. When requesting services, the client sends the following two messages to the TGS: o Message C: Composed of the Ticket-Granting Ticket from message B and the ID of the requested service. o Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key. 2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client: o Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key. o Message F: Client/server session key encrypted with the Client/TGS Session Key. Client Service Request Steps: 1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages: o Message E from the previous step (the client-to-server ticket, encrypted using service's secret key). o Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key. 2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client: o Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key. 3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server. 4. The server provides the requested services to the client. Drawbacks:
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology




• •

Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers. Kerberos requires the clocks of the involved hosts to be synchronized. The tickets have time availability period and, if the host clock is not synchronized with the clock of Kerberos server, the authentication will fail. The default configuration requires that clock times are no more than 10 minutes apart. In practice, Network Time Protocol daemons are usually used to keep the host clocks synchronized. The administration protocol is not standardized, and differs between server implementations. Password changes are described in RFC 3244. Since the secret keys for all users are stored on the central server, a compromise of that server will compromise all users' secret keys.

X509 In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. In the X.509 system, a CA issues a certificate binding a public key to a particular Distinguished Name in the X.500 tradition, or to an Alternative Name such as an email address or a DNS-entry. An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system. Browsers such as Internet Explorer, Netscape/Mozilla, Opera and Safari come with root certificates pre-installed, so SSL certificates from larger vendors who have paid for the privilege of being pre-installed will work instantly; in effect the browsers' owners determine which CAs are trusted third parties for the browsers' users. Although these root certificates can be removed or disabled, users rarely do so. If pre-installed root certificates are removed on the Microsoft-platform, the operating-system re-installs them as soon as a web-site using the certificate is visited[citation needed]. As this mechanism relies on hash-values, pre-installed with the operating system, it is not even possible to determine which certificates are permanently trusted. X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI systems. The IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Popular browsers like Internet Explorer and Firefox don't check for certificate revocation by default. The time lag for performing the checking could be one of the reasons. Structure of a certificate The structure of a X.509 v3 digital certificate is as follows:


Certificate o Version

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

• •

Serial Number Algorithm ID Issuer Validity  Not Before  Not After o Subject o Subject Public Key Info  Public Key Algorithm  Subject Public Key o Issuer Unique Identifier (Optional) o Subject Unique Identifier (Optional) o Extensions (Optional)  ... Certificate Signature Algorithm Certificate Signature
o o o o

Issuer and subject unique identifiers were introduced in Version 2, Extensions in Version 3. Usage: X.509 was initially issued on July 3, 1988 and was begun in association with the X.500 standard. It assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. This contrasts with web of trust models, like PGP, where anyone (not just special CAs) may sign, and thus attest to the validity of others' key certificates. Version 3 of X.509 includes the flexibility to support other topologies like bridges and meshes. It can be used in a peer-to-peer, OpenPGP-like web of trust, but was rarely used that way as of 2004. The X.500 system has never been fully implemented, and the IETF's Public-Key Infrastructure (X.509), or PKIX, working group has adapted the standard to the more flexible organization of the Internet. In fact, the term X.509 certificate usually refers to the IETF's PKIX Certificate and CRL Profile of the X.509 v3 certificate standard, as specified in RFC 3280 IP security Architecture: IPsec (IP security) is a suite of protocols for securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet in a data stream. IPsec also includes protocols for cryptographic key establishment. IPsec protocols operate at the network layer, layer 3 of the OSI model. Other Internet security protocols in widespread use, such as SSL, TLS and SSH, operate from the transport layer up (OSI layers 4 - 7). This makes IPsec more flexible, as it can be used for protecting layer 4 protocols, including both TCP and UDP, the most commonly used transport layer protocols. IPsec has an advantage over SSL and other methods that operate at higher layers: an application
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

doesn't need to be designed to use IPsec, whereas the ability to use SSL or another higher-layer protocol must be incorporated into the design of an application. IPsec is implemented by a set of cryptographic protocols for (1) securing packet flows, (2) mutual authentication and (3) establishing cryptographic parameters. The IP security architecture uses the concept of a security association as the basis for building security functions into IP. A security association is simply the bundle of algorithms and parameters (such as keys) that is being used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are secured by a pair of security associations. The actual choice of encryption and authentication algorithms (from a defined list) is left to the IPsec administrator. In order to decide what protection is to be provided for an outgoing packet, IPsec uses the security parameter index (SPI), an index to the security association database (SADB), along with the destination address in a packet header, which together uniquely identify a security association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the security association database. For multicast, a security association is provided for the group, and is duplicated across all authorized receivers of the group. There may be more than one security association for a group, using different SPIs, thereby allowing multiple levels and sets of security within a group. Indeed, each sender can have multiple security associations, allowing authentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevant standard does not describe how the association is chosen and duplicated across the group; it is assumed that a responsible party will have made the choice. Since the Internet Protocol does not inherently provide any security capabilities, IPsec was introduced to provide security services such as the following: 1. Encrypting traffic (so it cannot be read by parties other than those for whom it is intended) 2. Integrity validation (ensuring traffic has not been modified along its path) 3. Authenticating the peers (ensuring that traffic is from a trusted party) 4. Anti-replay (protecting against replay of the secure session). There are two modes of IPsec operation: transport mode and tunnel mode.

Transport mode
In transport mode, only the payload (the data you transfer) of the IP packet is encrypted and/or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be translated, as this will invalidate the hash value. The transport and application layers are always secured by hash,
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

so they cannot be modified in any way (for example by translating the port numbers). Transport mode is used for host-to-host communications. A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing the NAT-T mechanism.

Tunnel mode
In tunnel mode, the entire IP packet (data plus the message headers) is encrypted and/or authenticated. It must then be encapsulated into a new IP packet for routing to work. Tunnel mode is used for network-to-network communications (secure tunnels between routers, e.g. for VPNs) or host-to-network and host-to-host communications over the Internet. Two protocols have been developed to provide packet-level security for both IPv4 and IPv6:
• •

The IP Authentication Header provides integrity and authentication and non-repudiation, if the appropriate choice of cryptographic algorithms is made. The IP Encapsulating Security Payload provides confidentiality, along with optional (but strongly recommended) authentication and integrity protection.

Cryptographic algorithms defined for use with IPsec include HMAC-SHA1 for integrity protection, and TripleDES-CBC and AES-CBC for confidentiality. Refer to RFC 4305 for details. Authentication header (AH) The AH is intended to guarantee connectionless integrity and data origin authentication of IP datagrams. Further, it can optionally protect against replay attacks by using the sliding window technique and discarding old packets. AH protects the IP payload and all header fields of an IP datagram except for mutable fields, i.e. those that might be altered in transit. In IPv4, mutable (and therefore unauthenticated) IP header fields include TOS, Flags, Fragment Offset, TTL and Header Checksum. AH operates directly on top of IP, using IP protocol number 51. An AH packet diagram:

0 - 7 bit Next header

8 - 15 bit Payload length

16 - 23 bit RESERVED Sequence number Authentication data (variable)

24 - 31 bit

Security parameters index (SPI)

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

Field meanings: • • • • • • Next header o Identifies the protocol of the transferred data. Payload length o Size of AH packet. RESERVED o Reserved for future use (all zero until then). Security parameters index (SPI) o Identifies the security parameters, which, in combination with the IP address, then identify the security association implemented with this packet. Sequence number o A monotonically increasing number, used to prevent replay attacks. Authentication data o Contains the integrity check value (ICV) necessary to authenticate the packet; it may contain padding.

Encapsulating Security Payload (ESP) The ESP protocol provides origin authenticity, integrity, and confidentiality protection of a packet. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure.[2][3][4]. Unlike AH, the IP packet header is not protected by ESP. (Although in tunnel mode ESP, protection is afforded to the whole inner IP packet, including the inner header; the outer header remains unprotected.) ESP operates directly on top of IP, using IP protocol number 50.

An ESP packet diagram: 0 - 7 bit 8 - 15 bit 16 - 23 bit 24 - 31 bit

Security parameters index (SPI) Sequence number
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

Payload data (variable) Payload data (variable) Padding (0-255 bytes) Padding (0-255 bytes) Pad Length Next Header Authentication Data (variable) Field meanings: • • • • • • • Security parameters index (SPI) o Identifies the security parameters in combination with IP address. Sequence number o A monotonically increasing number, used to prevent replay attacks. Payload data o The data to be transferred. Padding o Used with some block ciphers to pad the data to the full length of a block. Pad length o Size of padding in bytes. Next header o Identifies the protocol of the transferred data. Authentication data o Contains the data used to authenticate the packet.

Secure Socket Layer

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

A simple connection example follows:


A Client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. The Server responds with a ServerHello, containing the chosen protocol version, a random number, cipher suite, and compression method from the choices offered by the client. The Server sends its Certificate (depending on the selected cipher suite, this may be omitted by the Server). These certificates are currently X.509, but there is also a draft specifying the use of OpenPGP based certificates.







The server may request a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest.

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology


The Server sends a ServerHelloDone message, indicating it is done with handshake negotiation. The Client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) The Client and Server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function". The Client now sends a ChangeCipherSpec message, essentially telling the Server, "Everything I tell you from now on will be encrypted." Note that the ChangeCipherSpec is itself a record-level protocol, and has type 20, and not 22. Finally, the Client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages. The Server will attempt to decrypt the Client's Finished message, and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down. Finally, the Server sends a ChangeCipherSpec and its encrypted Finished message, and the Client performs the same decryption and verification. At this point, the "handshake" is complete and the Application protocol is enabled, with content type of 23. Application messages exchanged between Client and Server will be encrypted.















Pretty Good Privacy Pretty Good Privacy (PGP) is a computer program that provides cryptographic privacy and authentication. PGP is often used for signing, encrypting and decrypting e-mails to increase the security of e-mail communications. PGP encryption uses public-key cryptography and includes a system which binds the public keys to a user name. The first version of this system was generally known as a web of trust to contrast with the X.509 system which uses a hierarchical approach based on certificate authority and which was added to PGP implementations later. Current versions of PGP encryption include both alternatives through an automated key management server. Digital signatures A similar strategy is used to detect whether a message has been altered since it was completed (the message integrity property), and whether it was actually sent by the person/entity claimed to
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

be the sender (a digital signature). In PGP, it is used by default in conjunction with encryption, but can be applied to plaintext as well. The sender uses PGP to create a digital signature for the message with either the RSA or DSA signature algorithms. To do so, PGP computes a hash (also called a message digest) from the plaintext, and then creates the digital signature from that hash using the sender's private keys. The message recipient uses the sender's public key and the digital signature to recover the original message digest. He compares this message digest with the message digest he computed her/himself from the (recovered) plaintext. If the signature matches the received plaintext's message digest, it must be presumed (to a very high degree of confidence) that the message received has not been tampered with, either deliberately or accidentally. As well, since it was properly signed, it is very likely (to a very high degree of confidence) that the claimed sender actually did send it. Web of trust Both when encrypting messages and when verifying signatures, it is critical that the public key one uses to send messages to someone or some entity actually does 'belong' to the intended recipient. Simply downloading a public key from somewhere is not overwhelming assurance of that association; deliberate (or accidental) spoofing is possible. PGP has, from its first versions, always included provisions for distributing a user's public keys in an 'identity certificate' which is so constructed cryptographically that any tampering (or accidental garble) is readily detectable. But merely making a certificate effectively which is impossible to modify without being detected is also insufficient. It can prevent corruption only after the certificate has been created, not before. Users must also ensure by some means that the public key in a certificate actually does belong to the person/entity claiming it. From its first release, PGP products have included an internal certificate 'vetting scheme' to assist with this; a trust model which has been called a web of trust. A given public key (or more specifically, information binding a user name to a key) may be digitally signed by a third party user to attest to the association between someone (actually a user name) and the key. There are several levels of confidence which can be included in such signatures. Although many programs read and write this information, few (if any) include this level of certification when calculating whether to trust a key. The web of trust protocol was first described by Zimmermann in 1992 in the manual for PGP version 2.0: As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys. The web of trust mechanism has advantages over a centrally managed PKI scheme such as that used by S/MIME, but has not been universally used. Users have been willing to accept
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

certificates and check their validity manually, or to simply accept them. The underlying problem has found no satisfactory solution. Certificates In the (more recent) OpenPGP specification, trust signatures can be used to support creation of certificate authorities. A trust signature indicates both that the key belongs to its claimed owner and that the owner of the key is trustworthy to sign other keys at one level below their own. A level 0 signature is comparable to a web of trust signature, since only the validity of the key is certified. A level 1 signature is similar to the trust one has in a certificate authority because a key signed to level 1 is able to issue an unlimited number of level 0 signatures. A level 2 signature is highly analogous to the trust assumption users must rely on whenever they use the default certificate authority list (like those included in web browsers); it allows the owner of the key to make other keys certificate authorities. PGP versions have always included a way to cancel ('revoke') identity certificates. A lost or compromised private key will require this if communication security is to be retained by that user. This is, more or less, equivalent to the certificate revocation lists of centralized PKI schemes. Recent PGP versions have also supported certificate expiration dates. The problem of correctly identifying a public key as belonging to a particular user is not unique to PGP. All public key / private key cryptosystems have the same problem, if in slightly different guise, and no fully satisfactory solution is known. PGP's original scheme, at least, leaves the decision whether or not to use its endorsement/vetting system to the user, while most other PKI schemes do not, requiring instead that every certificate attested to by a central certificate authority be accepted as correct. Security quality To the best of publicly available information, there is no known method which will allow a person or group to break PGP encryption by cryptographic, or computational means. Early versions of PGP have been found to have theoretical vulnerabilities and so current versions are recommended. Indeed, in 1996, cryptographer Bruce Schneier characterized an early version as being "the closest you're likely to get to military-grade encryption."[1] In contrast to security systems/protocols like SSL which only protect data in transit over a network, PGP encryption can also be used to protect data in long-term data storage such as disk files. The cryptographic security of PGP encryption depends on the assumption that the algorithms used are unbreakable by direct cryptanalysis with current equipment and techniques. For instance, in the original version, the RSA algorithm was used to encrypt session keys; RSA's security depends upon the one-way function nature of mathematical integer factoring. New, now unknown, integer factorization techniques might, therefore, make breaking RSA easier than now, or perhaps even trivially easy. However, it is generally presumed by informed observers that this is an intractable problem, and likely to remain so.[citation needed] Likewise, the secret key algorithm used in PGP version 2 was IDEA, which might, at some future time, be found to have a
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

previously unsuspected cryptanalytic flaw. Specific instances of current PGP, or IDEA, insecurities — if they exist — are not publicly known. As current versions of PGP have added additional encryption algorithms, the degree of their cryptographic vulnerability varies with the algorithm used. In practice, each of the algorithms in current use is not publicly known to have cryptanalytic weaknesses. Any agency wanting to read PGP messages would probably use easier means than standard cryptanalysis, e.g. rubber-hose cryptanalysis or black-bag cryptanalysis i.e. installing some form of trojan horse or keystroke logging software/hardware on the target computer to capture encrypted keyrings and their passwords. The FBI have already used this attack against PGP[2][3] in their investigations. However, it is important to note that any such vulnerabilities apply not just to PGP, but to all encryption software. An incident in December 2006 (see United States v. Boucher) involving US customs agents and a seized laptop PC which allegedly contained child pornography indicates that US Government agencies find it "nearly impossible" to access PGP-encrypted files. Additionally, a judge ruling on the same case in November 2007 has stated that forcing the suspect to reveal his PGP passphrase would violate his Fifth Amendment rights i.e. a suspect's constitutional right not to incriminate himself. S/MIME S/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in MIME. S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME specifies the application/pkcs7-mime (smime-type "envelopeddata") type for data enveloping (encrypting): the whole (prepared) MIME entity to be enveloped is encrypted and packed into an object which subsequently is inserted into an application/pkcs7mime MIME entity. S/MIME functionality is built into the vast majority of modern e-mail software and interoperates between them. Before S/MIME can be used in any of the above applications, one must obtain and install an individual key/certificate either from one's in-house certificate authority (CA) or from a public CA such as one of those listed below. Best practice is to use separate private keys (and associated certificates) for Signature and for Encryption, as this permits escrow of the encryption key without compromise to the non-repudiation property of the signature key. Encryption requires having the destination party's certificate on store (which is typically automatic upon receiving a message from the party with a valid signing certificate). While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, the S/MIME clients will require you install your own certificate before they allow encrypting to others.
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

A typical basic personal certificate verifies the owner's identity only in terms of binding them to an email address and does not verify the person's name or business. The latter, if needed (e.g. for signing contracts), can be obtained through CAs that offer further verification (digital notary) services or managed PKI service. For more detail on authentication, see Digital Signature. Depending on the policy of the CA, your certificate and all its contents may be posted publicly for reference and verification. This makes your name and email address available for all to see and possibly search for. Other CAs only post serial numbers and revocation status, which does not include any of the personal information. The latter, at a minimum, is mandatory to uphold the integrity of the public key infrastructure. Secure Electronic Transaction Secure Electronic Transaction (SET) is a standard protocol for securing credit card transactions over insecure networks, specifically, the Internet. SET is not itself a payment system, but rather a set of security protocols and formats that enables users to employ the existing credit card payment infrastructure on an open network in a secure fashion. SET was developed by VISA and MasterCard (involving other companies such as GTE, IBM, Microsoft, Netscape, RSA and VeriSign) starting in 1996. SET is based on X.509 certificates with several extensions. SET uses a blinding algorithm that, in effect, lets merchants substitute a certificate for a user's credit-card number. This allows traders to credit funds from clients' credit cards without the need of the credit card numbers. SET makes use of cryptographic techniques such as digital certificates and public key cryptography to allow parties to identify themselves to each other and exchange information securely. SET was heavily publicized in the late 1990's as the credit card approved standard, but failed to win market share. Reasons for this include:
• • •

Network effect - need to install client software (an e wallet). Cost and complexity for merchants to offer support and comparatively low cost and simplicity of the existing, adequate SSL based alternative. Client-side certificate distribution logistics.

SET was said to become the de facto standard of payment method on the Internet between the merchants, the buyers, and the credit-card companies. When SET is used, the merchant itself never has to know the credit-card numbers being sent from the buyer, which provide a benefit for e-commerce. Protocol:

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

People today pay for online purchases by sending their credit card details to the merchant. A protocol such as SSL or TLS keeps the card details safe from eavesdroppers, but does nothing to protect merchants from dishonest customers or vice-versa. SET addresses this situation by requiring cardholders and merchants to register before they may engage in transactions. A cardholder registers by contacting a certificate authority, supplying security details and the public half of his proposed signature key. Registration allows the authorities to vet an applicant, who if approved receives a certificate confirming that his signature key is valid. All orders and confirmations bear digital signatures, which provide authentication and could potentially help to resolve disputes. A SET purchase involves three parties: the cardholder, the merchant, and the payment gateway (essentially a bank). The cardholder shares the order information with the merchant but not with the payment gateway. He shares the payment information with the bank but not with the merchant. A set dual signature accomplishes this partial sharing of information while allowing all parties to confirm that they are handling the same transaction. The method is simple: each party receives the hash of the withheld information. The cardholder signs the hashes of both the order information and the payment information. Each party can confirm that the hashes in their possession agrees with the hash signed by the cardholder. In addition, the cardholder and merchant compute equivalent hashes for the payment gateway to compare. He confirms their agreement on the details withheld from him. All parties are protected. Merchants do not normally have access to credit card numbers. Moreover, the mere possession of credit card details does not enable a criminal to make a SET purchase; he needs the cardholder’s signature key and a secret number that the cardholder receives upon registration. The criminal would have better luck with traditional frauds, such as ordering by telephone. It is a pity that other features of SET (presumably demanded by merchants) weaken these properties. A merchant can be authorized to receive credit card numbers and has the option of accepting payments given a credit card number alone. SET is a family of protocols. The five main ones are cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. There are many minor protocols, for example to handle errors. SET is enormously more complicated than SSL, which merely negotiates session keys between the cardholder’s and merchant’s Internet service providers. Because of this complexity, much of which is unnecessary, the protocol is hardly used. However, SET contains many features of interest:


• •

The model is unusual. In the registration protocols, the initiator possesses no digital proof of identity. Instead, he authenticates himself by filing a registration form whose format is not specified. Authentication takes place outside the protocol, when the cardholder’s bank examines the completed form. The dual signature is a novel construction. The partial sharing of information among three peers leads to unusual protocol goals. SET uses several types of digital envelope. A digital envelope consists of two parts: one, encrypted using a public key, contains a fresh symmetric key K and identifying information; the other, encrypted using K, conveys the full message text. Digital

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

envelopes keep public-key encryption to a minimum, but the many symmetric keys complicate the reasoning. Most verified protocols distribute just one or two secrets. Firewall A firewall is a device or set of devices configured to permit, deny, encrypt, or proxy all computer traffic between different security domains based upon a set of rules or other criteria. A firewall is a dedicated appliance, or software running on another computer, which inspects network traffic passing through it, and denies or permits passage based on a set of rules. A firewall's basic task is to regulate some of the flow of traffic between computer networks of different trust levels. Typical examples are the Internet which is a zone with no trust and an internal network which is a zone of higher trust. A zone with an intermediate trust level, situated between the Internet and a trusted internal network, is often referred to as a "perimeter network" or Demilitarized zone (DMZ). A firewall's function within a network is similar to firewalls with fire doors in building construction. In the former case, it is used to prevent network intrusion to the private network. In the latter case, it is intended to contain and delay structural fire from spreading to adjacent structures. Without proper configuration, a firewall can often become worthless. Standard security practices dictate a "default-deny" firewall ruleset, in which the only network connections which are allowed are the ones that have been explicitly allowed. Unfortunately, such a configuration requires detailed understanding of the network applications and endpoints required for the organization's day-to-day operation. Many businesses lack such understanding, and therefore implement a "default-allow" ruleset, in which all traffic is allowed unless it has been specifically blocked. This configuration makes inadvertent network connections and system compromise much more likely. Scenario based questionnaire 1. What is the probable reason for getting 169.254.x.x?

Steps:1. Check the physical connection between the M-R-PC i.e. Ensure that the PC is connected to the LAN port and that the Modem is connected to the WAN/Internet port of the router. 2. Check the status of light on the LAN ports of the router where the PC is connected to.
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

3. Also check the Internet/WAN port light it should be lit 4. Do ipconfig/renew 5. Power cycle the network 6. Change the card speed of the NIC to 10 Mbps 7. Swap the ends of the cables 8. If possible connect different PC to the router and then check 9. Reset the router 10. Power cycle the network 11. Possibility of RMA or router gone bad 2. Bob is trying to setup his Linksys router for the first time what are the probable steps to configure the router. 1. Ensure that there is no USB connection between the M-PC 2. Check the physical connection between the M-R-PC 3. Check the status of light on the router 4. Do ipconfig/release and then ipconfig/renew 5. Check what is the IP, SM, Default gateway? 6. Ask him the type of ISP whether cable or DSL

If Cable ISP then follows the following steps:i) Do a Power cycle ii) Check if able to go online if not able to go online then ask him “Which is the PC when connected to the modem directly is able to go online ?” then go to that PC and note down the MAC address on a piece of paper.

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

iii) Open the setup page of the router by typing in the DG in the address bar (by default: 192.168.1.1) iv) Check whether it is an old firmware or a new firmware If Old firmware:Ask him to click on the “Advanced” tab-> MAC address clone-> Type the MAC address of the PC noted earlier If New Firmware:Ask him to Click on the “Setup”tab-> under the sub tab of “Mac Address Clone”-> Enable-> and then put the MAC address noted earlier v) Power cycle the network. If DSL ISP then follow the below steps:i) Do ipconfig/release and then ipconfig/renew ii) Note the default gateway and try to open the setup page of the router by typing it in the address bar iii) A small window pops up asking for username and password type “admin” as the password with no username or else asks if the customer has changed the password iv) Click on the “Status Tab” and check for the internet IP address a) If the Internet IP address is as follows:Internet IP address: 192.168.1.97 Subnet Mask : 255.255.255.0 Default Gateway : 192.168.1.254 v) Click on the “Setup” tab and under the Local IP change the LAN IP to 10.10.10.10 vi) Power cycle the network vii) Check if able to go online viii) If not ask the customer to convert the modem in a bridge mode
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

Click on the “Status Tab” and check for the internet IP address b) If the Internet IP address is as follows:Internet IP address: 0.0.0.0 Subnet Mask : 0.0.0.0 Default Gateway : 0.0.0.0 i) Click on the “Setup” tab and under the Internet Connection type select “PPPoE” and put in the [email protected] and the password:****** ii) Click on the “Status” tab and hit the “Connect” tab under the Login type PPPoE iii) Do a Power cycle 3. Bob is trying to setup his Linksys router for the first time and when on the setup page of the router on the “Status” he gets Security mechanism in java platform Security has been an integral part of Java technology from day one. Security is also an evolving design goal of the Java community—building and running secure and robust Java-based network applications. The primary reason for Java's success today as a secure execution environment is the intrinsic security of its architectural foundation—the Java Virtual Machine (JVM) and the Java language. This foundation achieves the basic Java security goal and its definitive ways for extending security capabilities to ensure features such as confidentiality, integrity, trust, and so forth. A second reason for its success is its ability to deliver an interoperable and platformneutral security infrastructure that can be integrated with the security of the underlying operating system and services. The Java Virtual Machine (JVM) The JVM is an abstract computing engine that resides on a host computer. It is the execution environment for the Java programming language and has the primary responsibility for executing the compiled code by interpreting it in a machine-independent and cross-platform fashion. The JVM is often referred to as the Java runtime environment. While executing a Java program running on top of the JVM, the JVM insulates the application from the underlying differences of the operating systems, networks, and system hardware, thus ensuring cross-platform compatibility among all of the implementations of the Java platform. The Java language allows creation of general-purpose programs called Java classes that represent a Java program or an application. The Java classes compile into a format called Java's executable
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

bytecodes, which are quite similar to the machine language that can run on top of a JVM. The JVM also allows users to download and execute untrusted programs and applications from remote resources or over a network. To support delivery of Java components over the network, the JVM controls the primary security layer by protecting users and the environment from malicious programs. To enable security, the JVM enforces stringent measures ensuring systems security on the host client machine and its target server environments. Distributing the executable Java bytecode over a network or running automatically inside a Web browser or a client's machine leads to different security risks and attacks, such as disclosure of the target environment to the untrusted applications and damage or modification of the client's private information and data. For example, Java applets downloaded from a network are not allowed to have access to, read from, or write to a local file system. They are also not allowed to create network connections to any host system except the one where they are deployed. On the other hand, stand-alone Java applications that reside and run locally as trusted applications are not subjected to these security features. The key issue is that allowing untrusted applications such as Java applets to be downloaded from a network via a Web browser and letting them access certain resources on the host computer paves the way for security breaches and becomes a potential avenue for the spread of viruses. To prevent known security breaches and threats, the JVM provides a built-in Java security architecture model, configurable security policies, access control mechanisms, and security extensions. Because of the built-in JVM safety features, Java programs can run safely and are more securely protected from known vulnerabilities. The Java Language Java is a general-purpose object-oriented programming language similar to C++. It delivers platform-neutral compiled code that can be executed using a JVM and is intended for use in distributed application environments, heterogeneous systems, and diverse network environments. The Java language is also designed to provide for the security and integrity of the application and its underlying systems at all levels—from the Java language constructs to the JVM runtime and from the class library to the complete application.The several inherent features of the Java language that provide for the secure Java platform are as follows:






The language defines all primitives with a specific size and all operations are defined to be in a specific order of execution. Thus, the code executed in different JVMs will not differ from the specified order of execution. The language provides access-control functionality on variables and methods in the object by defining name space management for type and procedure names. This secures the program by restricting access to its critical objects from untrusted code. For example, access is restricted by qualifying the type members as public, protected, private, package, etc. The Java language does not allow defining or dereferencing pointers, which means that programmers cannot forge a pointer to the memory or create code defining offset points to memory. All references to methods and instance variables in the class file are done via symbolic names. The elimination of pointers helps to prevent malicious programs like

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

• •





computer viruses and misuse of pointers such as accessing private methods directly by using a pointer starting from the object's pointer, or running off the end of an array. The Java object encapsulation supports "programming by contract," which allows the reuse of code that has already been tested. The Java language is a strongly typed language. During compile time, the Java compiler does extensive type checking for type mismatches. This mechanism guarantees that the runtime data type variables are compatible and consistent with the compile time information. The language allows declaring classes or methods as final. Any classes or methods that are declared as final cannot be overridden. This helps to protect the code from malicious attacks such as creating a subclass and substituting it for the original class and override methods. The Java Garbage Collection mechanism contributes to secure Java programs by providing a transparent storage allocation and recovering unused memory instead of deallocating the memory using manual intervention. This ensures program integrity during execution and prevents programmatic access to accidental and incorrect freeing of memory resulting in a JVM crash.

With these features, Java fulfills the promise of providing a secure programming language that gives the programmer the freedom to write and execute code locally or distribute it over a network. Java Built-in Security Model In the previous two sections, we briefly looked at the basic security features provided by the JVM and the Java language. As part of its security architecture, Java has a built-in policy-driven, domain-based security model. This allows implementing security policies, protecting/controlling access to resources, rule-based class loading, signing code and assigning levels of capability, and maintaining content privacy. In the first release of the Sun Java Platform, the Java Development Kit 1.0.x (JDK) introduced the notion of a sandbox-based security model. This primarily supports downloading and running Java applets securely and avoids any potential risks to the user's resources. With the JDK 1.0 sandbox security model, all Java applications (excluding Java applets) executed locally can have full access to the resources available to the JVM. Application code downloaded from remote resources, such as Java applets, will have access only to the restricted resources provided within its sandbox. This sandbox security protects the Java applet user from potential risks because the downloaded applet cannot access or alter the user's resources beyond the sandbox. The release of JDK 1.1.x introduced the notion of signed applets, which allowed downloading and executing applets as trusted code after verifying the applet signer's information. To facilitate signed applets, JDK 1.1.x added support for cryptographic algorithms that provide digital signature capabilities. With this support, a Java applet class could be signed with digital signatures in the Java archive format (JAR file). The JDK runtime will use the trusted public keys to verify the signers of the downloaded applet and then treat it as a trusted local application,
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

granting access to its resources. Figure 3-1 shows the representation of a sandbox in the JDK 1.1 security model.

Figure 3-1 JDK 1.1 security model Java 2 Security Model The release of J2SE [J2SE] introduced a number of significant enhancements to JDK 1.1 and added such features as security extensions providing cryptographic services, digital certificate management, PKI management, and related tools. Some of the major changes in the Java 2 security architecture are as follows:
• • • •

Policy-driven restricted access control to JVM resources. Rules-based class loading and verification of byte code. System for signing code and assigning levels of capability. Policy-driven access to Java applets downloaded by a Web browser.

In the Java 2 security architecture, all code—regardless of whether it is run locally or downloaded remotely—can be subjected to a security policy configured by a JVM user or administrator. All code is configured to use a particular domain (equivalent to a sandbox) and a security policy that dictates whether the code can be run on a particular domain or not. Figure 32 illustrates the J2SE security architecture and its basic elements.

Figure 3-2 Java 2 Security architecture and basic elements Let's take a more detailed look at those core elements of the Java 2 security architecture. Protection Domains (java.security.ProtectionDomain ): In J2SE, all local Java applications run unrestricted as trusted applications by default, but they can also be configured with accesscontrol policies similar to what is defined in applets and remote applications. This is done by configuring a ProtectionDomain, which allows grouping of classes and instances and then associating them with a set of permissions between the resources. Protection domains are generally categorized as two domains: "system domain" and "application domain." All protected
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

external resources, such as the file systems, networks, and so forth, are accessible only via system domains. The resources that are part of the single execution thread are considered an application domain. So in reality, an application that requires access to an external resource may have an application domain as well as a system domain. While executing code, the Java runtime maintains a mapping from code to protection domain and then to its permissions. Protection domains are determined by the current security policy defined for a Java runtime environment. The domains are characterized using a set of permissions associated with a code source and location. The java.security.ProtectionDomain class encapsulates the characteristics of a protected domain, which encloses a set of classes and its granted set of permissions when being executed on behalf of a user. Permissions ( java.security.Permission ): In essence, permissions determine whether access to a resource of the JVM is granted or denied. To be more precise, they give specified resources or classes running in that instance of the JVM the ability to permit or deny certain runtime operations. An applet or an application using a security manager can obtain access to a system resource only if it has permission. The Java Security API defines a hierarchy for Permission classes that can be used to configure a security policy. At the root, java.security.Permission is the abstract class, which represents access to a target resource; it can also include a set of operations to construct access on a particular resource. The Permission class contains several subclasses that represent access to different types of resources. The subclasses belong to their own packages that represent the APIs for the particular resource. Some of the commonly used Permission classes are as follows: For wildcard permissions For named permissions For file system For network For properties For runtime resources For authentication For graphical resources -java.security.AllPermission -java.security.BasicPermission -java.io.FilePermission -java.net.SocketPermission -java.lang.PropertyPermission -java.lang.RuntimePermission -java.security.NetPermission -java.awt.AWTPermission

Example 3-1 shows how to protect access to an object using permissions. The code shows the caller application with the required permission to access an object. Example 3-1. Using Java permissions to protect access to an object // Create the object that requires protection String protectedObj = "For trusted eyes only"; // create the required permission that will // protect the object. // Guard, represents an object that is used to protect // access to another object.
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

Guard myGuard = new PropertyPermission ("java.home", "read"); // Create the guard GuardedObject gobj = new GuardedObject(protectedObj, myGuard); // Get the guarded object try { Object o = gobj.getObject(); } catch (AccessControlException e) { // Cannot access the object } Permissions can also be defined using security policy configuration files (java.policy). For example, to grant access to read a file in "c:\temp\" (on Windows), the FilePermission can be defined in a security policy file (see Example 3-2). Example 3-2. Setting Java permissions in policy configuration file grant{ permission java.io.FilePermission "c:\\temp\\testFile", "read"; }; Policy: The Java 2 security policy defines the protection domains for all running Java code with access privileges and a set of permissions such as read and write access or making a connection to a host. The policy for a Java application is represented by a Policy object, which provides a way to declare permissions for granting access to its required resources. In general, all JVMs have security mechanisms built in that allow you to define permissions through a Java security policy file. A JVM makes use of a policy-driven access-control mechanism by dynamically mapping a static set of permissions defined in one or more policy configuration files. These entries are often referred to as grant entries. A user or an administrator externally configures the policy file for a J2SE runtime environment using an ASCII text file or a serialized binary file representing a Policy class. In a J2SE environment, the default system-wide security policy file java.policy is located at <JRE_HOME>/lib/security/ directory. The policy file location is defined in the security properties file with a java.security setting, which is located at <JRE_HOME>/lib/security/java.security. Example 3-3 is a policy configuration file that specifies the permission for a signed JAR file loaded from "http://coresecuritypatterns.com/*" and signed by "javaguy," and then grants read/write access to all files in /export/home/test. Example 3-3. Setting codebase and permissions in policy configuration file grant signedBy "javaguy", codebase "http://coresecuritypatterns.com/*" {
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

permission java.io.FilePermission "/export/home/test/*", "read,write"; }; The J2SE environment also provides a GUI-based tool called "policytool" for editing a security policy file, which is located at "<JAVA_HOME>/bin/policytool." By default, the Java runtime uses the policy files located in: ${java.home}/jre/lib/security/java.policy ${user.home}/.java.policy These policy files are specified in the default security file: ${java.home}/jre/lib/security/java.security The effective policy of the JVM runtime environment will be the union of all permissions in all policy files. To specify an additional policy file, you can set the java.security.policy system property at the command line: java -Djava.security.manager -Djava.security.policy=myURL MyClass To ignore the policies in the java.security file and only use the custom policy, use '==' instead of '=': java -Djava.security.manager -Djava.security.policy==Mylocation/My.policy MyClass SecurityManager ( java.lang.SecurityManager ): Each Java application can have its own security manager that acts as its primary security guard against malicious attacks. The security manager enforces the required security policy of an application by performing runtime checks and authorizing access, thereby protecting resources from malicious operations. Under the hood, it uses the Java security policy file to decide which set of permissions are granted to the classes. However, when untrusted classes and third-party applications use the JVM, the Java security manager applies the security policy associated with the JVM to identify malicious operations. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. In cases where the SecurityManager detects a security policy violation, the JVM will throw an AccessControlException or a SecurityException. In a Java application, the security manager is set by the setSecurityManager method in class System. And the current security manager is obtained via the getSecurityManager method (see Example 3-4).
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

Example 3-4. Using SecurityManager SecurityManager mySecurityMgr = System.getSecurityManager(); if (mySecurityMgr != null) { mySecurityMgr.checkWrite(name); } The class java.lang.SecurityManager consists of a number of checkXXXX methods like checkRead (String file) to determine access privileges to a file. The check methods call the SecurityManager.checkPermission method to find whether the calling application has permissions to perform the requested operation, based on the security policy file. If not, it throws a SecurityException. If you wish to have your applications use a SecurityManager and security policy, start up the JVM with the -Djava.security.manager option and you can also specify a security policy file using the policies in the -Djava.security.policy option as JVM arguments. If you enable the Java Security Manager in your application but do not specify a security policy file, then the Java Security Manager uses the default security policies defined in the java.policy file in the $JAVA_HOME/jre/lib/security directory. Example 3-5 programmatically enables the security manager. Example 3-5. Using SecurityManager for restricting access control // Before the security manager is enabled, // this call is possible System.setProperty("java.version","Malicious: Delete"); try { // Enable the security manager SecurityManager sm = new SecurityManager(); System.setSecurityManager(sm); } catch (SecurityException se) { // SecurityManager already set } // After the security manager is enabled: // This call is no longer possible; // an AccessControlException is thrown System.setProperty ("java.version", "Malicious: Delete"); The security manager can also be installed from the command-line interface: java -Djava.security.manager <ClassName>

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

AccessController ( java.security.AccessController ): The access controller mechanism performs a dynamic inspection and decides whether the access to a particular resource can be allowed or denied. From a programmer's standpoint, the Java access controller encapsulates the location, code source, and permissions to perform the particular operation. In a typical process, when a program executes an operation, it calls through the security manager, which delegates the request to the access controller, and then finally it gets access or denial to the resources. In the java.security.AccessController class, the checkPermission method is used to determine whether the access to the required resource is granted or denied. If a requested access is granted, the checkPermission method returns true; otherwise, the method throws an AccessControlException. For example, to check read and write permission for a directory in the file system, you would use the code shown in Example 3-6. Example 3-6. Using AccessController try { AccessController.checkPermission (new FilePermission("/var/temp/*", "read,write")); } catch (SecurityException e) { // Does not have permission to access the directory } Codebase: A URL location of class or JAR files are specified using codebase. The URL may refer to a location of a directory in the local file system or on the Internet. Example 3-7 retrieves all the permissions granted to a particular class that's been loaded from a code base. The permissions are effective only if the security manager is installed. The loaded class uses those permissions by executing Class.getProtectionDomain() and Policy.getPermissions(). Example 3-7. Using codebase class URL codebase = null; try { // Get permissions for a URL codebase = new URL("http://coresecuritypatterns.com/"); } catch (MalformedURLException e) { } catch (IOException e) { } // Construct a code source with the code base CodeSource cs = new CodeSource(codebase, null); // Get all granted permissions PermissionCollection pcoll = Policy.getPolicy().getPermissions(cs);
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

// View each permission in the permission collection Enumeration enum = pcoll.elements(); for (; enum.hasMoreElements(); ) { Permission p = (Permission)enum.nextElement(); System.out.println("Permission " + p); } To test Example 3-7, Example 3-8 is the policy file (test.policy), which provides permission to read all system properties. Example 3-8. Policy file for testing permissions to a codebase grant codebase "http://coresecuritypatterns.com/-" { // Give permission to read all system properties permission java.util.PropertyPermission "*", "read"; }; To ignore the default policies in the java.security file, and only use the specified policy, use '==' instead of '='. With the policy just presented, you may run the following: java -Djava.security.policy==test.policy TestClass CodeSource: The CodeSource allows representation of a URL from which a class was loaded and the certificate keys that were used to sign that class. It provides the same notion as codebase, but it encapsulates the codebase (URL) of the code where it is loaded and also the certificate keys that were used to verify the signed code. The CodeSource class and its two arguments to specify the code location and its associated certificate keys are as follows: CodeSource(URL url, java.security.cert.Certificate certs[]); To construct a code source with the code base and without using certificates, you would use the following: CodeSource cs = new CodeSource(codebase, null); Bytecode verifier: The Java bytecode verifier is an integral part of the JVM that plays the important role of verifying the code prior to execution. It ensures that the code was produced consistent with specifications by a trustworthy compiler, confirms the format of the class file, and proves that the series of Java byte codes are legal. With bytecode verification, the code is proved to be internally consistent following many of the rules and constraints defined by the Java language compiler. The bytecode verifier may also detect inconsistencies related to certain cases of array bound-checking and object-casting through runtime enforcement. To manually control the level of bytecode verification, the options to the Java command with the V1.2 JRE are as follows:
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology
• • •

-Xverify:remote runs verification process on classes loaded over network (default) -Xverify:all verifies all classes loaded -Xverify:none does no verification

ClassLoader: The ClassLoader plays a distinct role in Java security, because it is primarily responsible for loading the Java classes into the JVM and then converting the raw data of a class into an internal data structure representing the class. From a security standpoint, class loaders can be used to establish security policies before executing untrusted code, to verify digital signatures, and so on. To enforce security, the class loader coordinates with the security manager and access controller of the JVM to determine the security policies of a Java application. The class loader further enforces security by defining the namespace separation between classes that are loaded from different locations, including networks. This ensures that classes loaded from multiple hosts will not communicate within the same JVM space, thus making it impossible for untrusted code to get information from trusted code. The class loader finds out the Java application's access privileges using the security manager, which applies the required security policy based on the requesting context of the caller application. With the Java 2 platform, all Java applications have the capability of loading bootstrap classes, system classes, and application classes initially using an internal class loader (also referred to as primordial class loader). The primordial class loader uses a special class loader SecureClassLoader to protect the JVM from loading malicious classes. This java.security.SecureClassLoader class has a protected constructor that associates a loaded class to a protection domain. The SecureClassLoader also makes use of permissions set for the codebase. For instance, URLClassLoader is a subclass of the SecureClassLoader. URLClassLoader allows loading a class or location specified with a URL. Refer to Example 3-9, which shows how a URLClassLoader can be used to load classes from a directory. Example 3-9. Using URLClassLoader // Create a File object on the root of the // directory containing the class file File file = new File("c:\\myclasses\\"); try { // Convert File to a URL URL url = file.toURL(); URL[] urls = new URL[]{url}; // Create a new class loader with the directory ClassLoader myclassloader = new URLClassLoader(urls); // Load in the class; // MyClass.class should be located in
Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Not to be published to external person other than students of Rajagiri school of engineering and technology

// the directory file:/c:/myclasses/com/security Class myclass = myclassloader.loadClass("com.security.MySecureClass"); } catch (MalformedURLException e) { } catch (ClassNotFoundException e) { } Keystore and Keytool: The Java 2 platform provides a password-protected database facility for storing trusted certificate entries and key entries. The keytool allows the users to create, manage, and administer their own public/private key pairs and associated certificates that are intended for use in authentication services and in representing digital signatures.

Prepared by Abinas Akbar, visit  http://www.abiabinas.co.nr (for more course materials and updates) Reference: internet web sites

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close