Re: Encryption algorithm used for the IBMi OS passwords.

[Patrick Botz <pcbotz@xxxxxxxxx>]

That's not true, he last version of the OS to be certified was, as I
recall, prior to V5R1. I'm 99.9% sure it hasn't been done for V6.1 or
later.  It is very expensive to go through a common criteria (successor to
C2) certification.
On Mar 31, 2016 5:14 PM, "Roger Harman" <roger.harman@xxxxxxxxxxx> wrote:

> At security level 50, I believe IBM i is DOD C2 Certified.  Think that's
> good enough for them?
>
> Roger Harman
> COMMON Certified Application Developer - ILE RPG on IBM i on Power
>
>
>
>
> ________________________________________
> From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> on behalf of
> JWGrant@xxxxxxxxxxxxxxx <JWGrant@xxxxxxxxxxxxxxx>
> Sent: Thursday, March 31, 2016 3:06 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Encryption algorithm used for the IBMi OS passwords.
>
> I did find this tidbit on the IBM 7.2 Knowledge center that I found
> interesting.
> It does not disclose the algorithm used bit I did find in interesting.
>
> Jim
>
> Password Encryption and Storage on IBM i
> IBM i password encryption does not use a "hardcoded" encryption key in
> either of the password encryption algorithms so there is no key that needs
> to be stored or protected. The encryption algorithms use the USERID and
> the PASSWORD itself in the encryption algorithm. Before actually
> encrypting and/or hashing (depending on the setting of the QPWDLVL system
> value), there are a few additional steps that are performed to essentially
> drop off a few of the bits that make up the clear text password followed
> by an "exclusive or" operation on the password string (this helps protect
> the password). This password string is then used to encrypt or hash the
> user ID in order to create the encrypted password. Since the password
> itself becomes the key, things are very secure as a key does not need to
> be stored anywhere on the system. When it is time to authenticate a user,
> the system takes the clear text password that the user entered (on the
> signon screen, etc.) and runs the same algorithm, then compares that
> encrypted result with the encrypted result that was created and saved when
> the password was changed. There is never a comparison that is done with
> the clear text password itself since the encryption algorithms are both
> one-way, meaning you can never decrypt and get back the clear text
> password.
> The user profile passwords are stored in an internal control block that is
> protected with the strongest mechanism available to the IBM i operating
> system running on the Power® hardware. A capability that is called
> Hardware Storage Protection (HSP) is used to protect the control block.
> The HSP capability is protection that is built into the Power hardware and
> enforced by the hardware itself. The HSP value that is used is called "no
> access from user state" and "protect at all security levels". This HSP
> protection value keeps all user level code out of the control block (no
> read or write access) but allows the operating system to read/write the
> control block. This protection is always activated as the control block is
> protected at all security levels. If user level code tries to access the
> control block, the hardware would send an exception and the Licensed
> Internal Code would send an error to the user level code (and access would
> be denied).
> If someone has the encrypted password could they decrypt it to get the
> clear text password?
> No, but a brute force attack is possible, basically running all potential
> passwords through the algorithm and comparing the encrypted results. So it
> is important to protect your SAVSYS and SAVSECDTA tapes and data by using
> encrypted backup with tape hardware capable of encryption. The operating
> system protects the passwords by storing them in an internal control block
> that is protected with the strongest mechanism available to the operating
> system on the Power hardware. HSP is used to protect the control block.
> But the passwords are saved on media during a SAVSYS and SAVSECDTA so the
> media needs to be protected (encrypted backup and physical security).
> One thing to be aware of is that the system has two IBM i APIs, set
> encrypted password (QSYSUPWD) and retrieve encrypted password (QSYRUPWD )
> that were implemented to allow the High Availability (HA) business
> partners the ability to move user profile changes from the production
> machine to the target side backup server. These APIs allow the retrieve
> and set of the encrypted password for a user profile but the APIs are only
> callable by a security officer (*ALLOBJ and *SECADM special authority
> required). These APIs do return the encrypted password string so this data
> and the use of the API need to be well controlled. The HA partners use
> these APIs to move the password to the target server when a password
> changes on the production server in order to keep the password change in
> sync. The encrypted password string, and other information, returned by
> the QSYRUPWD API have a cyclic redundancy check (CRC) created to ensure
> the password itself is not modified (either intentionally or accidentally)
> when being moved from system to system. The CRC is checked by the QSYSUPWD
> API to ensure that the string is the same as when it was returned by
> QSYRUPWD. This CRC does not provide any protection for the encrypted
> password itself, it just ensures that the string isn't changed before
> setting the password on the target server. To protect the encrypted
> password in the HA environment (along with all data flowing from source to
> target), an encrypted session between the source and target system is
> recommended.
>
>
> Jim W Grant
> Senior VP, Chief Information Officer
> Web: www.pdpgroupinc.com
> Email: JWGrant@xxxxxxxxxxxxxxx
>
>
>
>
> From:   Nathan Andelin <nandelin@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   03/31/2016 05:34 PM
> Subject:        Re: Encryption algorithm used for the IBMi OS passwords.
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> My dad worked on the encryption algorithms for U.S. military missile and
> rocket guidance systems.. He passed away, but I wonder how he would
> respond
> to "auditors"?
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.