Most applications have some form of password protection that keeps unauthorized personnel out of areas in which they do not belong. The problem with most of these security systems is that someone can usually defeat them if that someone is in possession of any real technical abilities. There should be some way for you to keep your company data secure without having to write your own encryption routines.

Cryptography has been around as long as mankind has had secrets to keep. It has been used to protect everything from military plans in wartime to credit card numbers when you make a purchase over the Internet. Cryptography is about keeping secrets. Well, we are going to let you in on a well-kept secret about the AS/400: OS/400 provides you with a suite of APIs to encrypt data. What this means to you is that encryption is not just for Big Brother anymore. As the Internet continues its explosive growth, more and more companies are attaching their AS/400s to the Internet. The marriage of the Internet and the AS/400 forces developers like us to employ security measures we have never had to before. Luckily, attaching the AS/400 to the Internet is easy.

Retrofitting legacy code to work securely while running in that environment is another matter, however. When you attach an AS/400 to the Internet, you have opened a portal that makes your data available from anywhere in the world. There are all kinds of measures that can help protect your data, and one of those measures is encryption. Encryption is a tool used to retrofit your legacy applications. Most applications have some kind of built-in security requiring a password. A menu system wants a password before you can run an option or has a pop-up window that asks for a password to perform a special function. Usually, you can store these passwords in a data area or a file and then view them with easily accessible, system-provided commands. In other words, somebody that knows what to do has a good chance of discovering those passwords. If you encrypt the passwords, they cannot be viewed by anybody.

Shaken, Not Stirred

As shown in Figure 1, the RPG program encrypts passwords for you. It allows you to add users and their passwords to the system, remove users from the system, or validate the user/password combination. We have written this program as an external program that you call to verify users and passwords. It is strongly recommended that you use this program as a guide and clone the code into your program so that the password does not have to be

passed as a parameter. Passing a password as a parameter is a security violation in itself, but it’s better than storing it in a file.

The first step in the process is to create a validation list, which is an object on the AS/400 (type *VLDL) that stores the encrypted password. You use the Create Validation List (CRTVLDL) command to create a list. You must have security clearance to operate this command. Just give the list a meaningful name and designate a library for it to reside in. To use the program provided, you must create a validation list called PWLIST in library QGPL.

Now, you need to add a user to the list. The first three parameters that the program expects are an action code, a user profile, and a password to encrypt. Use action code “A” to add the user and password to the list; use action code “D” to delete the user from the list; and use action code “V” to verify that the password is correct. The next two parameters are the return code and error text. These parameters return error information regarding your request. The return code field is set to “N” if the password is invalid or the request failed, and the error text gives feedback information from the API about the reason for the failure. The description parameter is used only when adding a new user to the list. It allows you to further describe the entry. There are other APIs, such as Find Validation List Entry (QsyFindValidation LstEntry), that retrieve this description and allow you to see all of the users on the validation list.

Keeping Secrets

Let’s take a closer look at the code. The ADDPW subroutine executes the ADDPASS function. If we look at the prototype for ADDPASS, we see that it executes the external Add Validation List Entry (QsyAdd ValidationLstEntry) API. The procedure wants five parameters, four of the parameters are mandatory, and the other one is optional. The OPTIONS(*OMIT) keyword on the ATRIBDSH parameter indicates that we don’t have to pass this parameter. The first parameter is the name of the validation list and is hardcoded to QGPL/PWLIST. The next three parameters are data structures.

The ENTRYIDDS data structure contains the name of the user profile preceded by two 4-byte binary fields that contain the length of the user profile data and the CCSID code. The user profile length is 10, and we use zero for the CCSID code, which stores the default CCSID for the current user. The user profile name does not have to exist on the system. You could devise some kind of coding scheme to encrypt data, based on something other than the user profile. Valid values for the profile length are one to 100. The ENCRIPDS data structure follows the same format as the ENTRYIDDS data structure. But this data structure contains the password. Valid values for the length of the encrypted data are one to
600. The ENTRYDS data structure also follows the same format and contains your description of the ENTRYID field. Valid values for the length of the description are one to 1,000. We have elected to omit the fifth parameter. This parameter is an attribute data structure that allows you to change default values. By default, encrypted passwords cannot be viewed in their original form. This means you cannot look at the decrypted password using any method. You can verify a password, but you can’t see it. There are APIs that return the data in its original, decrypted state, but only if you enable this function when you first add the entry to the validation list. This attribute data structure parameter enables this function. Because we are accepting the default value for this option, we can omit the parameter.

If the entry is successfully added to the validation list, the field ADD contains zero. If it is not successful, the field contains a -1 and the ERRNO global value is set to indicate the error. Most APIs use an optional error data structure as a parameter to pass back error conditions, but these APIs are different. The APIs in this article are of the C language type and, like the C language itself, much more difficult to follow. We’re sure that this will offend all of the C programmers out there (both of you) who are reading this, but really, how many RPG programmers know what a “union data type” is and how to define it in

RPG IV? Since we’re on the subject, why are all the examples in the manuals written in C when RPG is still the dominant language on the AS/400? The APIs would be a lot easier to use if the examples were shown in a language that somebody actually uses on the AS/400!

The global value ERRNO is accessed in an RPG program through the external procedure “__errno”, which we have defined on the prototype C_Errno. It returns a pointer that you can use to retrieve a text description of the error. If you think that RPG and CPF messages were created by demented, dyslexic cryptographers who weren’t very happy with their assignment in the first place, you should be forewarned. It gets worse. The description of the errors returned by C-type APIs make us wonder if anyone at IBM knows the definition of the word description.

The validation function is provided through the VLDPW subroutine. If you pass a “V” in the action code, this subroutine gets executed. It, in turn, executes the Verify Validation List Entry (QsyVerifyValidation LstEntry) API. This is a relatively simple API, but it makes the whole encryption process work. You give the API the name of the validation list, the name of the user profile (or key), and the password to verify, using the ENTRYIDDS and ENCRIPDS data structures. If the password is invalid, the procedure returns a -2. The program then sets the RTNCODE field to “N” so the calling program knows that the password is invalid.

The delete function is provided through the DLTPW subroutine. Pass in a “D” in the action code, and this subroutine gets executed. It uses the Remove Validation List Entry (QsyRemoveValidationLstEntry) API to accomplish this task. Pass this procedure the name of the validation list and the name of the user profile (again, through the ENTRYIDDS data structure), and it removes the user from the list.

Loose Lips Sink Ships

We would like to thank one of our favorite ex-IBMers, Jon Paris, for the code, enabling us to retrieve the ERRNO value. Without his help, we wouldn’t have been able to work our way through these APIs. With the help of Jon, we have done the hard part for you. These encryption techniques can be valuable for securing your data. We would strongly recommend adding them to your programming toolbox. After all, in the bigger picture, tightened security is a small price to pay for the advantages of global computing.

*==================================================================

* TO COMPILE: (signed on as QSECOFR)

*

* CRTBNDRPG PGM(XXXLIB/VLD016RG) SOURCE(XXXLIB/QRPGLESRC)

* USRPRF(*OWNER) DFTACTGRP(*NO) ACTGRP(QILE) BNDDIR(QC2LE)

*

*==================================================================

*

* VLD016Rg = Program performs 3 functions:

* Action code A = Add encrypted password to system

* D = Delete encrypted password from system

* V = Validate password passed to system

*

d AddPass PR 10i 0 ExtProc('QsyAddValidation+
d LstEntry')
d ListName 20
d EntryIdDsH 18
d EncriptDsH 18
d EntryDSH 58
d AtribDsH 47 options(*omit)

d Action s 1
d Add s 10i 0 inz(0)
d Description s 50
d Dlt s 10i 0 inz(0)
d ErrorText s 70
d ErrorVal s 10i 0 based(@errorVal)
d PassWord s 10
d Rtncode s 1
d UserId s 10

* Validation list name
d ListNameA s 20 inz('PWLIST QGPL ')

* Prototype for validation API
d ValidPass PR 10i 0 ExtProc('QsyVerifyValidation+
d LstEntry')
d ListName 20
d EntryIdDs 18
d EncriptDs 18

* Prototype for remove API
d DeletePass PR 10i 0 ExtProc('QsyRemoveValidation+
d LstEntry')
d ListName 20
d EntryIdDs 18

* Prototype for error retrieval
d C_Errno PR * extproc('__errno')
d C_Strerror PR * extproc('strerror')
d errno 10i 0 value

* Entry Id list (user profile name or key value)
D EntryIdDs DS INZ
D IdLength 1 4b 0 inz(10)
D CCSIDLen 5 8b 0 inz(0)
D EntUserId 9 18

* Password to encript
D EncriptDs DS INZ
D EncripLen 1 4b 0 inz(10)
D CCSIDEnc 5 8b 0 inz(0)
D EncripData 9 18

* Free-form description of item
D EntryDs DS INZ
D EntryLen 1 4b 0 inz(50)
D CCSIDEnt 5 8b 0 inz(0)
D EntryData 9 58

c *entry plist
c parm Action
c parm UserId
c parm PassWord
c parm RtnCode
c parm ErrorText
c parm Description

c eval EntUserId = UserId
c eval EncripData = Password
c eval ErrorText = *blanks
c Action caseq 'A' AddPw
c Action caseq 'D' DltPw
c Action caseq 'V' VldPw
c endcs

* Trap any errors that may have occurred
c eval @errorval = C_Errno
c if errorval <> 0
c if %parms > 4
c eval ErrorText = %str(C_Strerror(ErrorVal))
c eval RtnCode = 'N'
c endif
c clear ErrorVal
c endif

c eval *inlr = *on

* Add password to system
c AddPw Begsr
c eval EntryData = Description
c eval Add = (AddPass(ListnameA:
c EntryIdDs:EncriptDs:
c EntryDS:*omit))
c endsr * Validate password
c VldPw Begsr
c If (ValidPass(ListnameA:
c EntryIdDs:EncriptDs)) 0
c eval RtnCode = 'N'
c endif
c endsr * Delete password
c DltPw Begsr
c eval Dlt = (DeletePass(ListnameA:
c EntryIdDs))
c endsr

Figure 1: Cut and paste portions of program VLD016RG to add password encryption to your programs.

Also Read

The API Corner: Moving Jobs Within and Across Job Queues

The API Corner: What Time Zone Do You Want That Date and Time In?

The API Corner: How Do You Want That Date and Time?