[A bug] enckey / HSM not ready

Hello,

I managed to protect the enckey with the securitymodule and it works fine,
I restart apache, the status if false, I type my admin password, then the
password for the key, the status is true and everything works fine. However
after few hours, I logged in as admin into the system and I was not able to
retrieve the user “LDAP” data and the logs shows:

[ERROR][privacyidea.lib.token:387] User information can not be retrieved:
ERR707: hsm not ready!

and I have to decrypt the key again. Not sure what causes this.

Regards,
Sherif

Okay, it seems that the logrotate profile for apache2 is the reason, it
rotates the logs everyday and then it reloads Apache server and that clears
the key from the memory I guess… any work around :slight_smile: ?

SherifOn Wednesday, December 9, 2015 at 11:46:45 AM UTC, Sherif Nagy wrote:

after a bit of deep investigation, it seems that Debian includes a daily
Cron that clear the apache2 cache, will check it, try again and keep you
updated.

Sherif

On Wednesday, December 9, 2015 at 11:35:49 AM UTC, Sherif Nagy wrote:

Hello,

I managed to protect the enckey with the securitymodule and it works
fine, I restart apache, the status if false, I type my admin password, then
the password for the key, the status is true and everything works fine.
However after few hours, I logged in as admin into the system and I was not
able to retrieve the user “LDAP” data and the logs shows:

[ERROR][privacyidea.lib.token:387] User information can not be retrieved:
ERR707: hsm not ready!

and I have to decrypt the key again. Not sure what causes this.

Regards,
Sherif

after a bit of deep investigation, it seems that Debian includes a daily
Cron that clear the apache2 cache, will check it, try again and keep you
updated.

SherifOn Wednesday, December 9, 2015 at 11:35:49 AM UTC, Sherif Nagy wrote:

Hello,

I managed to protect the enckey with the securitymodule and it works fine,
I restart apache, the status if false, I type my admin password, then the
password for the key, the status is true and everything works fine. However
after few hours, I logged in as admin into the system and I was not able to
retrieve the user “LDAP” data and the logs shows:

[ERROR][privacyidea.lib.token:387] User information can not be retrieved:
ERR707: hsm not ready!

and I have to decrypt the key again. Not sure what causes this.

Regards,
Sherif

Hi Sherif,

this works as expected. The key is only accessible for the current
process. The password to encrypt the key is contained in the memory
allocated by the current process.

If you would have the password anywhere else, you would not have to
encrypt the key. You can still rely on the default file access
protection of the encryption key.

You can however increase the logrotate time for apache. Then you would
have to reenter the password only once a week or one a month.

Imagine creating a service, that passes the password to the apache
process. There is no secure way to assure that the apache process and
not another process accesses the password.

What attack scenarios did you want to mitigate in the first place?

Kind regards
CorneliusAm Mittwoch, den 09.12.2015, 03:57 -0800 schrieb Sherif Nagy:

Okay, it seems that the logrotate profile for apache2 is the reason,
it rotates the logs everyday and then it reloads Apache server and
that clears the key from the memory I guess… any work around :slight_smile: ?

Sherif

On Wednesday, December 9, 2015 at 11:46:45 AM UTC, Sherif Nagy wrote:
after a bit of deep investigation, it seems that Debian
includes a daily Cron that clear the apache2 cache, will check
it, try again and keep you updated.

    Sherif
    
    On Wednesday, December 9, 2015 at 11:35:49 AM UTC, Sherif Nagy wrote:
            Hello,
            
            
            I managed to protect the enckey with the
            securitymodule and it works fine, I restart apache,
            the status if false, I type my admin password, then
            the password for the key, the status is true and
            everything works fine. However after few hours, I
            logged in as admin into the system and I was not able
            to retrieve the user "LDAP" data and the logs shows:
            
            
            [ERROR][privacyidea.lib.token:387] User information
            can not be retrieved: ERR707: hsm not ready!
            
            
            and I have to decrypt the key again. Not sure what
            causes this.
            
            
            Regards,
            Sherif


You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/5d8d081b-0725-4850-8df8-7d01c9e8e822%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

Hi Cornelius,

Well I moved it to be monthly. Nothing in particular, I am just testing
everything with PrivacyIDEA also it would be a good idea to have an
encrypted enckey within the offsite backup, I know that can be done via
actual encryption which still an option as well.

Regards,
SherifOn Wednesday, December 9, 2015 at 12:52:42 PM UTC, Cornelius Kölbel wrote:

Hi Sherif,

this works as expected. The key is only accessible for the current
process. The password to encrypt the key is contained in the memory
allocated by the current process.

If you would have the password anywhere else, you would not have to
encrypt the key. You can still rely on the default file access
protection of the encryption key.

You can however increase the logrotate time for apache. Then you would
have to reenter the password only once a week or one a month.

Imagine creating a service, that passes the password to the apache
process. There is no secure way to assure that the apache process and
not another process accesses the password.

What attack scenarios did you want to mitigate in the first place?

Kind regards
Cornelius

Am Mittwoch, den 09.12.2015, 03:57 -0800 schrieb Sherif Nagy:

Okay, it seems that the logrotate profile for apache2 is the reason,
it rotates the logs everyday and then it reloads Apache server and
that clears the key from the memory I guess… any work around :slight_smile: ?

Sherif

On Wednesday, December 9, 2015 at 11:46:45 AM UTC, Sherif Nagy wrote:
after a bit of deep investigation, it seems that Debian
includes a daily Cron that clear the apache2 cache, will check
it, try again and keep you updated.

    Sherif 
    
    On Wednesday, December 9, 2015 at 11:35:49 AM UTC, Sherif Nagy  wrote: 
            Hello, 
            
            
            I managed to protect the enckey with the 
            securitymodule and it works fine, I restart apache, 
            the status if false, I type my admin password, then 
            the password for the key, the status is true and 
            everything works fine. However after few hours, I 
            logged in as admin into the system and I was not able 
            to retrieve the user "LDAP" data and the logs shows: 
            
            
            [ERROR][privacyidea.lib.token:387] User information 
            can not be retrieved: ERR707: hsm not ready! 
            
            
            and I have to decrypt the key again. Not sure what 
            causes this. 
            
            
            Regards, 
            Sherif 


You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea...@googlegroups.com <javascript:>.
To post to this group, send email to priva...@googlegroups.com
<javascript:>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/privacyidea/5d8d081b-0725-4850-8df8-7d01c9e8e822%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
corneliu…@netknights.it <javascript:>
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

Hi Sherif,

you can backup the encryption key encrypted in any way - e.g. gpg.
You can store it even offline.

You can use

pi-manage backup

to run backups.

Kind regards
CorneliusAm Donnerstag, den 10.12.2015, 12:21 -0800 schrieb Sherif Nagy:

Hi Cornelius,

Well I moved it to be monthly. Nothing in particular, I am just
testing everything with PrivacyIDEA also it would be a good idea to
have an encrypted enckey within the offsite backup, I know that can be
done via actual encryption which still an option as well.

Regards,
Sherif

On Wednesday, December 9, 2015 at 12:52:42 PM UTC, Cornelius Kölbel wrote:
Hi Sherif,

    this works as expected. The key is only accessible for the
    current 
    process. The password to encrypt the key is contained in the
    memory 
    allocated by the current process. 
    
    If you would have the password anywhere else, you would not
    have to 
    encrypt the key. You can still rely on the default file
    access 
    protection of the encryption key. 
    
    You can however increase the logrotate time for apache. Then
    you would 
    have to reenter the password only once a week or one a month. 
    
    Imagine creating a service, that passes the password to the
    apache 
    process. There is no secure way to assure that the apache
    process and 
    not another process accesses the password. 
    
    What attack scenarios did you want to mitigate in the first
    place? 
    
    Kind regards 
    Cornelius 
    
    
    Am Mittwoch, den 09.12.2015, 03:57 -0800 schrieb Sherif Nagy: 
    > Okay, it seems that the logrotate profile for apache2 is the
    reason, 
    > it rotates the logs everyday and then it reloads Apache
    server and 
    > that clears the key from the memory I guess.. any work
    around :) ? 
    > 
    > 
    > Sherif 
    > 
    > On Wednesday, December 9, 2015 at 11:46:45 AM UTC, Sherif Nagy wrote: 
    >         after a bit of deep investigation, it seems that
    Debian 
    >         includes a daily Cron that clear the apache2 cache,
    will check 
    >         it, try again and keep you updated. 
    >         
    >         
    >         Sherif 
    >         
    >         On Wednesday, December 9, 2015 at 11:35:49 AM UTC, Sherif Nagy  wrote: 
    >                 Hello, 
    >                 
    >                 
    >                 I managed to protect the enckey with the 
    >                 securitymodule and it works fine, I restart
    apache, 
    >                 the status if false, I type my admin
    password, then 
    >                 the password for the key, the status is true
    and 
    >                 everything works fine. However after few
    hours, I 
    >                 logged in as admin into the system and I was
    not able 
    >                 to retrieve the user "LDAP" data and the
    logs shows: 
    >                 
    >                 
    >                 [ERROR][privacyidea.lib.token:387] User
    information 
    >                 can not be retrieved: ERR707: hsm not
    ready! 
    >                 
    >                 
    >                 and I have to decrypt the key again. Not
    sure what 
    >                 causes this. 
    >                 
    >                 
    >                 Regards, 
    >                 Sherif 
    > -- 
    > You received this message because you are subscribed to the
    Google 
    > Groups "privacyidea" group. 
    > To unsubscribe from this group and stop receiving emails
    from it, send 
    > an email to privacyidea...@googlegroups.com. 
    > To post to this group, send email to
    priva...@googlegroups.com. 
    > To view this discussion on the web visit 
    >
    https://groups.google.com/d/msgid/privacyidea/5d8d081b-0725-4850-8df8-7d01c9e8e822%40googlegroups.com. 
    > For more options, visit https://groups.google.com/d/optout. 
    
    -- 
    Cornelius Kölbel 
    corneliu...@netknights.it 
    +49 151 2960 1417 
    
    NetKnights GmbH 
    http://www.netknights.it 
    Landgraf-Karl-Str. 19, 34131 Kassel, Germany 
    Tel: +49 561 3166797, Fax: +49 561 3166798 
    
    Amtsgericht Kassel, HRB 16405 
    Geschäftsführer: Cornelius Kölbel 


You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/7cd8bfa6-6a3c-47d4-9100-893f268e54aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)