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.
midrange.com
