Encryption madness. Holy crap

Well, it started about month ago with the following case:

My customer got an idea that it would be great to adopt CMIS for some integration routines, because CMIS is a standard, has OOTB implementation, etc, etc, etc… Well, if CMIS is a standard try it on your own and don’t bother me… but no suck luck – all DFC-based applications seem to be specially designed to do not work properly out-of-the-box. The CMIS challenge was the following: customer has about 3000 CMIS clients which within a short period of time load a couple of documents into Documentum repository, customer expected about 100-200 simultaneous connections, which is not a big deal for Content Server, but, as it turned out, 100-200 simultaneous connections it is a big challenge for CMIS. The problem is that CMIS considers all requests which contain the same credentials (i.e. login and password are the same for all requests) as requests from the same client, and for all requests containing the same credentials CMIS uses the only one repository session. Here’s an interesting point: three yeas ago EMC introduced “Intelligent Session Management” feature (see also Ask the Expert: Features + Benefits of EMC Documentum D7 and xCP 2.0 Favourite Thing #20: Powered by D7) which was intended to somehow improve session management, but even now a lot of DFC applications use its own square wheels, which cause a lot of pain in behind.

Well, what do we need to do if using the same credentials across across CMIS clients causes performance issues? I was considering two options:

  1. create dedicated account for each CMIS client – obvious, but requires to change permission logic as well
  2. take advantage of “encrypted” passwords – it allows to “generate different passwords”:
    API> encryptpass,c,dmadmin
    ...
    DM_ENCR_PASS_V2=AAAAEMdecoR51kuUZPXibPRM3a33NpNcQeCzwwqjlWtP8VV3gzMEDUdarrP12Ti0KbNDJSTegm70gbVJrOypK6qiFHA=
    API> encryptpass,c,dmadmin
    ...
    DM_ENCR_PASS_V2=AAAAEJIEZY3ZCuzJRBw1lrKifaoosOe7MjU4XuySVQC1J2fbfK6IpGDH7XOw/aNJd/raPU0vfoIH1+zRE+3vkfzrVBw=
    API> encryptpass,c,dmadmin
    ...
    DM_ENCR_PASS_V2=AAAAECcfEKMv8bsLZ5UIQy/0fmyKqVxy5OL/Yk+Nn9TEhRRnqM/7zJqWtbTMfDeVMk6MaIWudNFcFmSSJ/u6C8M0HZo=
    API> encryptpass,c,dmadmin
    ...
    DM_ENCR_PASS_V2=AAAAELFBEgQ1vVaJ0rJ1y4dMOQVgkFRQSCxC91IOkmYWKg5lb/cR3f0E3onkye75QsrF1AtV2GoTGvCCssRyPItU7as=
    

I had chosen the second one a got a lot of fun. Let’s explain.

At first, in order to confirm my concerns about performance, I had created a test plan in Apache JMeter, after that I generated a set of encrypted passwords. If you have no idea how “encrypted passwords” feature should work I recommend to read Content Server API Reference Manual pages 108 and 159 to make sure that this feature was documented. The general idea is following:

  • We create a brand new aek.key file on CS side:
    [dmadmin@docu72dev01 ~]$ dm_crypto_create -location /tmp/aek.key -noprompt
    
    ** Will use default passphrase **
    
    
    ** Will use default algorithm **
    
    Please wait. This will take a few seconds ...
    Key - aek.key uses algorithm AES_128_CBC. 
    
    ** A key store already exists under /tmp/aek.key
    
  • After that we can generate encrypted passwords using initcrypto and encryptpass commands:
    Connected to Documentum Server running Release 7.2.0030.0195  Linux64.Oracle
    Session id is s0
    API> initcrypto,c,/tmp/aek.key
    ...
    OK
    API> encryptpass,c,test_password
    ...
    DM_ENCR_PASS_V2=AAAAEDAafp9V6OXlKarZHoN4k....
    API>      
    
  • in order to take advantage of encrypted passwords on application side, we need to transfer previously generated aek.key file on application’s filesystem and start application with “DM_CRYPTO_FILE” environment variable pointing to location of aek.key file

And only after a series of tests I had realised that I had missed two important steps (frankly speaking, I was bothered more by visualising results in Apache JMeter):

  • call initcrypto before generating passwords
  • copy aek.key onto CMIS filesystem

meanwhile Apache JMeter was working smoothly! What the hell is going on? Actually, I already mentioned that in Documentum 7.2 EMC had performed a couple of weird changes related to security: Encryption madness, Encryption madness. Part II, also month ago Yuri Simione discovered another funny behaviour in Documentum 7.2: EMC Documentum 7.2 migration and Murphy’s laws, and this is another one “security” feature of Documentum 7.2: now Content Server accepts encrypted password as they were plain text!

One thought on “Encryption madness. Holy crap

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s