Tag: PKI

Way cool ! HTTP Session Hijacking can’t be made simpler than using Firesheep. Couple of days ago, a friend of mine suggested me to login a most popular website and he demonstrated how he took control and accessed my user session in less than a minute. First, I thought he used a network protocol analyser tool such as Wireshark or sniffer to access my session information…but I was a bit surprised to see he used a simple and user friendly Firefox plugin (Firesheep) to steal and access my session information. Believe it or not – in an unsecured network,  Firesheep can easily capture active user session information exchanged with a Website that uses clear-text/unencrypted HTTP communication and session ID cookies irrespective of their underlying Operating System and user’s Browser. Ofcourse sending and receiving clear-text over HTTP has always posed a huge risk and compromising the session cookie allows impersonation….. interestingly majority of us don’t care much till we become a victim  of a data loss !  Even the many popular social network websites still uses clear-text over HTTP.



With my first experience, Firesheep worked well on my Mac… capturing my Facebook and WordPress sessions running on a PC… so quick ! Not just Facebook sessions – if you are using an unsecured/clear network and accessing any unsecured web site (without SSL), Firesheep can act as a “Man-in-the-Middle” attacker who can comfortably capture, hijack and obtain unauthorized access to the currently active user’s HTTP session. Unfortunately, there is no silver bullet to thwart these attacks unless you are aware and avoid the risks of using unsecured networks and clear-text communication.




Thwarting Firesheep !

If you are concerned about Firesheep attacks on the client side (user’s browser) then make sure to use a Secured VPN or Secure Shell (SSH) or IPSec or Encrypted WiFi (ex.WPA2) connection for accessing unsecured web applications. In case of accessing from unsecured networks, you may use Blacksheep tool which helps to find out whether your user session is currently being captured by a rogue Firesheep user on the network. In case of accessing Facebook, you may consider using HTTPS Everywhere a firefox extension that allows to rewrite Facebook requests and other HTTPS supported Websites.

On the server-side, if you are curious about securing your web application and user sessions from prying eyes….here is some best practices that can help thwarting similar session hijacking attacks:

  1. Use SSL/TLS communication to ensure encrypted transport between the user’s client and Web server.
  2. Use encrypted session cookies and use encrypt/decryption mechanisms for setting and getting of cookie data.
  3. Enable Hostname/IP address verification for all critical requests,  identify and compare the current user’s host with the originating user’s host in the user’s session cookie.

If you are concerned about SSL/TLS overheads and looking for high-performance SSL/TLS acceleration solutions then refer to my previous entries..that would able to help you.



Goodluck.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

I’ve spent the last few days attending Oracle OpenWorld conference at San Francisco..it is my second OOW experience, so it is not a surprise to see the conference was fully packed with people, hundreds of sessions and demos – I did have an opportunity to attend few and also present two sessions focused on Security topics featuring “Hardware Assisted Security Solution for SOA, XML Web Services and Java EE applications” – showcasing how “Hardware and Software Engineered together”.



During the conference, John Fowler – Oracle EVP, Systems announced the industry’s first 16 core processor introducing new SPARC T3 systems with integrated security and virtualization capabilities. Each SPARC T3 processor features 16 on-chip cryptographic accelerators that deliver cryptographic operations running in parallel at CPU speeds and offloading compute-intensive cryptographic functions from software – thus eliminating the need for additional special-purpose cryptographic accelerators such as PCIe cards or network appliances. The cryptographic operation offload and acceleration is accomplished using dedicated cryptographic accelerator drivers, called the Niagara Crypto Provider (NCP), Niagara 2 Crypto Provider (N2CP) and Niagara 2 Random Number Generator (N2RNG). In practice, the NCP and N2CP accelerators uses the Oracle Solaris Cryptographic Framework for enabling user-level applications to off-load cryptographic operations via PKCS#11 standard interfaces and take advantage of NCP and N2CP based on-chip cryptographic acceleration. The current UltraSPARC T3 processors provide acceleration support for public-key encryption mechanisms including RSA, DSA, DH and ECC algorithms,  symmetric key-based encryption amechanisms including DES, 3DES, AES and Kasumi algorthms and Message disgest/hashing mechanisms MD5, SHA1, SHA-256 and SHA-512 algorithms. The Solaris Cryptographic Framework (SCF) library plays a vital role for providing applications access to NCP and N2CP accelerators through a set of cryptographic services for kernel-level and user-level consumers. Using PKCS#11 interfaces of Solaris Cryptographic Framework, SOA and Java EE Applications (ex. Oracle Fusion Middleware, WebLogic, Glassfish, JBoss, Websphere)  can take advantage of NCP and N2CP based cryptography acceleration (Refer figure).



Hardware Assisted Cryptographic Acceleration using Solaris on UltraSPARC T3 Servers





Cryptographic Acceleration for SOA and Java EE Security



Both SOA/XML Web services and Java EE based applications can significantly gain on security performance by offloading and delegating their cryptographic operations to the on-chip cryptographic accelerators of Oracle SPARC Enterprise T-Series servers.



Applied Security Mechanisms and Usage Scenarios



To enhance security performance, both the Oracle WebLogic server and Oracle WSM secured applications can offload select cryptographic operations to address the following security scenarios.



  • Transport-layer Security
    • SSL/TLS acceleration offloads computationally intensive public-key cryptographic operations such as RSA, DH and ECC.
    • RMI over IIOP with SSL uses SSL/TLS to protect IIOP connections to RMI remote objects.
  • Message-Layer Security
    • Acceleration of cryptographic operations intended for supporting XML Web Services security standards such as WS-Security, WS-SecurityPolicy. XML Web services security relies on public-key encryption, digital signature (ex. RSA, DSA), bulk encryption (ex. AES, 3DES,DES) and message digest (ex. SHA-1, SHA-2, MD5) functions intended for supporting XML encryption, XML digital signature and related cryptographic operations.


Performance Characteristics



Based on a performance study, Oracle’s SPARC Enterprise T3-1 server was used to evaluate both SSL and WS-Security application performance of a SOA/XML Web Services application deployed on Oracle Fusion Middleware (WebLogic 10.3.3 and Oracle Web Services Manager).



  • Enabling on-chip acceleration for SSL (Cipher suite using RSA-1024/AES-256) and WS-Security (Algorithm suite using Basic256Rsa15) usecases  solidly delivered between 2X – 3X overall application throughput performance gain  in comparison with SSL and WS-Security usecases running with no acceleration.
  • Using Oracle Solaris KSSL as an SSL proxy provided an additional performance gain of about 25-30% outperforming WebLogic server SSL configured using Java SunPKCS11 provider for enabling cryptographic acceleration.



Now, you got the highlights,  if you are ready to dig deeper on the details and test-drive the solution – Please download and read the following two whitepapers (available from Oracle Technology network)  that explores the above solution from ground up.


If you are curious to see the OOW presentation – It is right here.



Thanks to Vikas Jain, Nitin Handa and Chad Prucha for all the help and support on this effort.

Don’t forget to let me know, if you had any comments and suggestions.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

When it comes to Java cryptography based application security –  Solaris has significant performance advantage over Linux and Windows on Intel Westmere processor equipped servers.  I am not debunking Linux performance on Intel but evidently Linux does not take advantage of Intel Westmere’s AES-NI instructions when the Java applications relies on Java cryptographic implementations  for performing AES encryption/decryption functions.  AES is one of the most popular symmetric-key encryption algorithm widely used in security transaction protocols (SSL/TLS, IPSEC),  Disk encryption,  Database encryption,  XML Web Services security standards (WS-Security) and so forth. If you are a Java  security enthusiast or a developer who is curious about Intel Westmere and Java security – here is some observations:




Intel introduced the new 32nm Westmere processors family (Xeon processor 5600 series) that incorporates  instructions for AES algorithm (AES-NI) to faster cryptographic applications that uses AES – a symmetric-key encryption standard.  AES is a block cipher, with a fixed block size of 128 bits that encrypts and decrypts data using multiple rounds where the number of rounds (10, 12, or 14) depends on the keysize (128, 192 or 256 bits). The Intel’s AES-NI implementation consists of seven new instructions for AES  algorithm - AESENC, AESENCLAST, AESDEC, AESDECLAST, CLMUL, AESIMC, and AESKEYGENASSIST to support performing computations for 10 (128 Bit), 12 (192 Bit), and 14 (256 Bit) rounds and most operational modes including ECB, CBC and CTR.  AES-NI accelerates AES based encryption/decryption operations in the CPU by offloading them from the software and eliminates its time spent in AES encryption/decryption functions. This means applications relying on AES algorithm can delegate its AES encryption/decryption functions to Intel’s AES-NI.  To enable applications make use of Intel AES-NI, it is critical that the applications must be recompiled to use Intel’s Integrated Performance Primitives (Intel IPP) library that contains functions and optimizations for achieving AES performance using AES-NI on Intel Westmere processors. Assuming the applications are recompiled and optimized to include Intel’s IPP library – applications can benefit from AES-NI features of Intel Westmere.


Intel Westmere - AES-NI (Source: pcsstats.com)

Intel Westmere - AES-NI (Source: pcsstats.com)





Java Security: The Solaris Advantage



With the release of Solaris 10 Update 8 and above,  Solaris 10  introduced support for Intel AES-NI through integration with Solaris Cryptographic Framework (SCF).  As Solaris Cryptographic Framework acts as the intermediary for cryptographic operations, all applications relying on Solaris based PKCS#11 provider APIs, CLIs and Solaris kernel modules will automatically take advantage of AES-NI instructions for AES encryption and decryption. More importantly, with AES-NI integration -  Java SE/Java EE applications using JDK’s SunPKCS11 provider for supporting Java Cryptographic Extensions (JCE) and Java Secure Socket Extensions (JSSE),  applications using OpenSSL with Solaris PKCS11 and Mozilla NSS  with Solaris PKCS11 automatically use Intel AES-NI accelerating AES encryption/decryption operations on Solaris.



By default on Solaris, the Sun JDK and its JCE provider environment uses a Sun PKCS#11 implementation (SunPKCS11) that allows Java applications to access Solaris managed software/hardware cryptographic services. The SunPKCS11 provider is a Java based PKCS#11 implementation that integrates with underlying Solaris PKCS#11 implementations provided by the SCF and its exposed cryptographic providers (ex. Intel AES-NI). In a typical JDK installation on Solaris, the Java runtime environment is pre-configured to make use of the SunPKCS11 provider. To verify this refer to the Java security properties file located at $JAVA_HOME/jre/lib/security/java.security properties file and make sure it identifies SunPKCS11 as the default provider.



security.provider.1=sun.security.pkcs11.SunPKCS11     ${java.home}/lib/security/sunpkcs11solaris.cfg



The $JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfg file contains the configuration information used by the SunPKCS11 provider for accessing the SCF.  To leverage AES-NI acceleration, it is important to enable and enforce delegation of the required cryptographic mechanisms to the underlying Solaris PKCS#11 provider that facilitates the AES-NI acceleration support. Make sure to include the required AES mechanisms (ex. CKM_AES) in the Java SunPKCS11 provider configuration file that lists as part of  enabledMechanisms  list or removes the mechanisms from the list of disabledMechanisms  of the Java SunPKCS11 configuration file. Doing so forces the required AES operations  performed by Intel AES-NI.



For SSL scenarios using AES for bulk encryption,  it is important that the Java application server’s SSL configuration is enforced to use TLS_*_AES* cipher suites (-Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA). For WS-Security scenarios using AES for XML Encryption scenarios, it is required to choose WS-SecurityPolicy using algorithm suite that includes AES ciphers. If the WS-SecurityPolicy specified algorithm suite is Basic256Rsa15, it uses Aes256 encryption and Rsa-oaep-mgf1p for key wrap. To enable acceleration, you need to remove the required bulk encryption algorithms in the disabledMechanisms list that forces those operations (ex. CKM_AES) performed by Intel AES-NI.




AES-NI Performance on Solaris for SSL and WS-Security

As I tested on a Xeon 5660 based server, using AES-NI for securing Java EE applications and XML Web services on Solaris 10 Update 9 showed significant SSL and WS-Security performance gains on Solaris 10.  The SSL performance (RSA-1024/AES-256) showed 30% – 40% performance gain over not using AES-NI and WS-SecurityPolicy (using Basic256Rsa15) showed about 2X – 3X performance on XML encryption and decryption operations.  Certainly Java security applications has strong advantage while running on Solaris on Intel Westmere processor based servers.


I am not a performance guru…but in my opinion Java Cryptographic performance on Linux (Intel Westmere) has NO EFFECT as Linux lacks support for a software PKCS#11 provider that takes advantage of AES-NI.  If your Java applications has significant AES workloads then Solaris 10 is ideal choice on Intel Westmere based servers.




Try it out and let me know your comments.



Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Hardware Security Module (HSM) plays a critical role in securing the storage of private keys and accelerating compute-intensive cryptographic processes associated with public-key encryption, symmetric-key(secret-key) encryption and digital signature applications. Using HSM in Oracle Transparent Data Encryption applications will ensure that the Key material stored on the card is protected and not exportable (never leaves the card) and all associated cryptographic operations are performed on the card. Using HSM in payment card transactions is critical and it is mandatory for compliance with Payment Card Industry – Data Security Standard (PCI-DSS), Payment Application – Data Security Standard (PA-DSS) and Health Insurance Portability and Accountability Act (HIPAA) privacy and security requirements and several government security standards.



Oracle Transparent Data Encryption


Oracle Transparent Data Encryption (TDE) was first introduced in Oracle Database 10gR2 as part of the Oracle Advanced Security option. TDE performs encryption and decryption of application table columns or entire application tablespaces. TDE uses standard algorithms and facilitates a built-in key management services for supporting data encryption. Since Oracle Database 11gR1, TDE supports HSMs using PKCS#11 interface to support providing centralized key management and to secure TDE’s master encryption key.




Sun Cryptographic Accelerator 6000 (SCA-6000)



The Sun Crypto Accelerator 6000 is a PCI-E card that combines a cryptographic accelerator for Secure Sockets Layer (SSL) and IPSec sessions and also it can act as a local HSM for performing secure key management functions. Qualified as a FIPS 140-2 Level 3 compliant device, the SCA-6000 PCI-E card is designed to prevent the disclosure or corruption of cryptographic keys, results, or other sensitive data. SCA-600o supports both Solaris and Linux environments.



Applied Scenarios


  • HSM based Secure key store and Master Key Management for supporting encryption and decryption of keys performing actual data encryption:
    1. Encryption/decryption of tablespace keys and table keys
    2. Encryption/decryption support for Oracle Data Pump utility
    3. Encryption/decryption support for Oracle Recovery Manager (RMAN)
    4. Master key backup and recovery
  • FIPS-140-2 Level 3 compliance
  • Acceleration of Network encryption -  SSL/TLS communication between the Oracle client and server.
    • Offloading computationally intensive cryptographic operations to the accelerator

The Role of SCA-6000 as a HSM for Oracle TDE




If you are curious to know the configuration details and ready to test-drive the solution using Sun Crypto Accelerator 6000 (SCA-6000) PCIe card for Oracle TDE – Please download and read the following whitepaper (available from Sun Wiki).





Don’t forget to post your comments.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

In a typical Single Sign-On (SSO)/Federation scenario using SAML, the Service Provider (SP) initiates the user authentication request using SAML AuthnRequest assertion with an Identity Provider (IDP). The IDP authenticates the principal and returns a SAML AuthnStatement assertion response confirming the user authentication. If the user is successfully authenticated, the SP is required to have the subject’s profile attributes of the authenticated principal for making local authorization decisions. To obtain the subject’s profile attributes (ex. organization, email, role), the SP initiates a SAML AttributeQuery request with the target IDP.  The IDP returns a response SAML AttributeStatement assertion listing the name of the attributes and the associated values.  Using the subject’s profile attributes, the SP can perform authorization operations.

 

Ofcourse, it looks simple…here is the complexity – Last two weeks I spent on building a Proof-of-Concept that conforms to HSPD-12 Back-end Attribute Exchange specifications and SAMLv2 Attribute Sharing Profile for X.509 Authentication based systems (Both specifications are mandated as part of Federal Identity, Credential and Access Management (ICAM) initiative of Federal CIO Council).  I had been experimenting with an Identity Federation scenario that makes use of Smartcard/PKI credentials – Card Authentication Key (CAK)/X.509 Certificate on a PIV card authenticates a PKI provider (using OCSP) and then using its X.509 credential attributes (Subject DN) for looking up off-card user attributes from an IDP (that acts as an Attribute Authority). The IDP provides the user profile attribute information to the requesting SP. In simpler terms, the SP initiated X.509 authentication directly  via OCSP request/response with a Certificate Validation Authority (VA) of a Certificate Authority (CA). Upon successful authentication, the SP  initiates a SAML AttributeQuery to the IDP (which acts as an Attribute Authority), the SAML AttributeQuery uses the SubjectDN of the authenticated principal from the X.509 certificate and requests the IDP to provide the subject’s user profile attributes.

 

Using Fedlet for SAML X.509 Authentication based Attribute Sharing

 

SAML Attribute Exchange for X.509 based Authentication

 

Fedlet is a lightweight SAMLv2 based Service Provider (SP) implementation (currently part of Sun OpenSSO 8.x and sooner to be available in Oracle Identity Federation) for enabling SAMLv2 based Single Sign-On environment. In simpler terms, Fedlet allows an Identity Provider (IDP) to enable an SP that need not have federation implemented. The SP plugs in the Fedlet to a Java/.NET web application and then ready to initiate SAML v2 based SSO authentication, authorization and attribute exchanges.  A Fedlet installed and configured with a SP can set up to use multiple IDPs where select IDPs can acts as Attribute Authorities. In this case, the Fedlet need to update its configuration with the IDP Metadata configuration (such as entity ID, IDP Meta Alias, Attribute Authority Meta Alias – same as IDP ). In addition, the Fedlets are capable of performing XML signature verification and decryption of responses from the IDP must identify the alias of signing and encryption certificates.

Here is the quick documentation, which I referred  for putting together the solution using Fedlets for SAMLv2 Attribute Sharing for X.509 based authentication scenarios. In case, if you want your Service Provider to use OpenSSO for PIV/CAC based certificate authentication, you may refer to my earlier entry on Smartcard/PKI authentication based SSO (Using OpenSSO). Besides that you should be good to test-drive your excercise. Ofcourse, you can use Fedlets for Microsoft .NET service providers but it was’nt in my scope of work !

 

In case of SP requiring to fetch multiple user profile attributes you may also choose to use SPML based queries (SPML Lookup/Update/Batch Request/Response) to an Identity Manager (acting as Attribute Authority) – assuming it facilitates an SPML implementation). If you are looking for a solution that requires user profile attributes after a single-user X.509 authentication, then SAML Attribute query should help fetching a single user profile of an authenticated principal !
:-)

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

With increasing incidents of online frauds through username/password compromises and stolen/forged identity credentials - Strong authentication using multi-factor credentials is often considered as a  defensive solution for ensuring high-degree of identity assurance to accessing  Web applications. Adopting multi-factor credentials based authentication has also become a most common security requirement for enabling access control to critical online banking transactions and to safeguard online customer information  (Mandated by FFIEC authentication guidelines). One-time Passwords using Tokens, USB dongles, Java Smartcards/SIM cards, Mobile Phones and other specialized devices has become the most simplest and effective option that can be easily adopted as the “second-factor credential (Something I have)” for strong authentication solution.   Although…and there is a myriad ways to create one-time passwords, the overwhelming developer issue is to make it to work by readily integrating it with existing applications and further enabling them for use in Web SSO and Federation scenarios.

 

One-time Password (OTP) Authentication using OpenSSO

 

The One-time password (OTP) is commonly generated on a physical device such as a token and is entered by the user at the time of authentication, once used it cannot be reused which renders it useless to anyone that may have intercepted it during the authentication process.

Sun OpenSSO Enterprise 8.x offers a ready-to-use OTP based authentication module that allows to deliver One-time passwords via SMS (on Mobile phones) and Personal email or combination of both. OpenSSO implements Hashed Message Authentication Code (HMAC) based One-time password (HOTP) algorithm as defined in RFC 4226 - an IETF – OATH (Open Authentication) joint initiative. The HOTP is based on HMAC-SHA-1 algorithm - using an increasing 8-bit counter value and a static symmetric key that is known to the HOTP generator and validation service.  In a typical OpenSSO deployment, the HOTP authentication module is configured to work as part of an authentication chain that includes a first-factor authentication (ex. Username/Password authentication with LDAP, Datastore). This means that atleast one of the existing authentication must be performed successful before commencing HOTP authentication.

 

Try it yourself

To deploy OTP for Web SSO authentication, all you would need is to have OpenSSO Enterprise 8.x and configured up and running…. and then follow these steps:

  1. Login to OpenSSO Administrator console, select the “Access Control” tab, select your default “Realm”, select “Authentication”. Click on “Module Instances” and click on “New” to create a Module instance. Assign a name to the module instance (ex. HOTP) and select “HOTP” as type.
  2. Configure the HOTP authentication module properties.  You need to identify the values for Authentication Level, SMTP Server (Access credentials including host name, port, username, password), One-time password validity length (Maximun validity time valid since creation and before OTP expires), One-time Password length (6 or 8 digits), One-time Password Delivery (“SMS” or “Email” or “Both” to receive SMS and Email). 
    •  
      Configuring HOTP Authentication Module Properties

      Configuring HOTP Authentication Module Properties

       

  3. Configure an Authentication Chain that includes HOTP authentication module with any other authentication module (ex. Datastore, LDAP). You may note HOTP authentication cannot act as primary authentication since it HOTP authentication does not identify the user profile, so it must be combined with an authentication module that identifies the calling user identity. To create an authentication chain… goto the OpenSSO administrator console, select “Access Control”, Goto “Authentication Chaining”, click on “New”, assign a name to the authentication chain (ex. Two-factor”) and the choose “HOTP” module instance and select “Required”.
    •  
      Configuring the Two-factor authentication chain including HOTP

      Configuring the Two-factor authentication chain including HOTP

       

  4. Now the OpenSSO One-time Authentication Module is ready for use as par of “Two-factor” authentication chain.
  5. Create an User Profile that identifies the user’s “Telephone Number” attribute with the Mobile Phone Number appended with the SMS Gateway domain.
  6.  Test drive the configured One-time Password based SSO authentication, by accessing the URL of the configured “Two-factor” authentication chain as follows:
  7. As a result, you will be prompted to perform username/password authentication and then followed by HOTP. To deliver One-Time Password, click “Request OTP Code”, the One-time password will be delivered to your Mobile via SMS and also via email (provided in your User profile).
    • One-time Password based SSO

      One-time Password based SSO

    • As verified using my Blackberry…the OTP showed up as follows:    

  

Adopting to One-time Pasword based authentication credentials certainly helps to defend against many illegitimate access using compromised user credentials such as Passwords, PIN and Digital certificates.  Using OpenSSO based OTP authentication is just a no-brainer… try it for yourselves, I am sure you will enjoy !

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Drone video feeds got eavesdropped ?

Interesting news..I am not sure how far this story is true !  The Iraqi insurgents has used the SkyGrabber utility to eavesdrop the live video feeds from the US Drones…as reported by Wallstreet journal yesterday.  Quite interesting to note, the multi-million dollar unmanned aircraft did’nt use “Encrypted Communication” in first place.

It’s time for them to deploy a tamper-proof encrypted communication for ensuring high-degree of confidentiality and integrity…without compromising the performance, so a wire-speed cryptography solution might help..as posted in my previous entry

:-)

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Important Disclaimer:The information presented in this weblog is provided “AS IS” with no warranties, and confers no rights. It solely represents our opinions. This weblog does not represent the thoughts, intentions, plans or strategies of our employers.
.