News

What Is This?

Theory

Security

Try It Out!

FAQs

Presentation

Download

Building the Server

Software Experiments

Building the Server



Overview

There are two potential reasons why you might be interested in building the RPOW server program. The first is that you may want to run your own RPOW server. You will need to acquire an IBM 4758-002 secure coprocessor card to do this, because that is the only architecture where the RPOW server will run. The second, and more common, purpose is to create a memory image file from the source code published for the RPOW server, which matches the memory image file distributed with the RPOW system. By hashing that file and comparing with the hash reported by the remote system, you can convince yourself that the source code is a true and accurate representation of the program running on the 4758 secure coprocessor.

The discussion here will be oriented towards this second goal, of successfully reproducing the memory image which was loaded into the 4758. If you do have a 4758 of your own and want to build RPOW to run on it, the same steps will work for that purpose as well.

The build instructions are for building on a Linux system. The RPOW memory image was built using Linux GCC. It might be possible to run these tools on a Windows system, using Cygwin to let you run GCC, but there is no guarantee that this would work, and that the memory image that resulted would be the same.

Acquiring the tools

In order to build an exact copy of the RPOW memory image (executable program) loaded into the 4758, it will be necessary to use exactly the same development tools. A different version of the compiler, assembler, linker, or the IBM post-processing tools could produce a different result. Since it is necessary for the result to be 100% identical to that which was built and downloaded into the 4758 server, the same tools must be used.

The tools necessary are:

Unfortunately, as of early 2005 the free Alphaworks toolkit has been removed from the IBM web site. For now, please contact me for information on finding alternative sources for this resource.

There are two binary files, lxscctk.tz for Linux systems, and winscctk.zip for Windows NT and 2000. You need to download them both. Although we will be building on Linux, the Linux toolkit is missing two header files which are necessary for the build. They are present in the NT version. Follow the instructions below to copy the missing header files from the NT zip file.

The GNU tools are relatively old versions, but the IBM tools will not work with newer ones. There was a change in the linker output format around the time of GCC 3.0, and the IBM post-processing steps will not work with files produced by later GNU tools.

I will assume that you have a relatively modern Linux system with a different version of GCC installed. We will build a "cross-compiler" version of GCC which will reside in its own directory and be used only to build the RPOW memory image. It will not affect or harm your distribution's version of GCC in any way.

Note that the link for GCC above is just for the "core" version; there is no need for the entire toolkit just for this application. RPOW is written in C and only that language is needed.

Preparation

First, download the tools above, and unpack them into their own directories. (Note: for the .zip file, use the -a command to unzip so that text files get line endings approrpriate for a Linux file system.) I will assume that they are all unpacked into directories that are children of a single root directory that will be used throughout this process, which I will call WD (for Working Directory). Throughout this description I will refer to file names like WD/scctk. You should substitute for WD the name of your own directory where you unpacked the tools.

Unpacking the tools should produce four subdirectories:

  • gcc-2.95.3
  • binutils-2.10.1
  • scctk
  • scctk-NT

The first two are the GNU tools; the third is the Linux version of the coprocessor toolkit; and the fourth is the NT version of the coprocessor toolkit. IBM uses the letters scc to stand for Secure Cryptographic Corprocessor in their naming conventions, and I have followed that policy as well.

The next thing we will do is to build the cross compiler. CD into the WD and follow these steps (remember to replace WD with your own working directory path): 

mkdir cross
mkdir build-binutils
mkdir build-gcc
export TARGET=i386-linux-gnu
export PREFIX=WD/cross
cd build-binutils
../binutils-2.10.1/configure --target=$TARGET --prefix=$PREFIX --disable-nls
make all install
export PATH=$PATH:$PREFIX/bin:$PREFIX/$TARGET/bin
cd ../build-gcc
../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX --disable-nls \
	--enable-languages=c --without-headers --with-newlib
make all-gcc install-gcc

These instructions assume you have an sh type shell like bash. If you have a csh type shell, you will need to replace the EXPORT commands with setenv, as in 

setenv TARGET i386-linux-gnu
and similarly for the other environment variables.

This should create a GCC toolchain inside of WD/cross/bin. The files have the prefix i386-linux-gnu, as in i386-linux-gnu-gcc.

The next step is to copy the missing header files from scctk-NT to scctk: 

cp WD/scctk-NT/002/include/common/scc*oa.h WD/scctk/include/common
This will copy two files: scc_oa.h and scc_mboa.h. The scctk-NT directory will not be used further.

Finally, edit the PATH to include the IBM development tools: 

export PATH=$PATH:WD/scctk/bin/linux

Those are all the preparatory steps necessary.

Building

Now we are ready to build the memory image. There are several steps, but they are all automated by the Makefile supplied with the RPOW source. Some editing of the Makefile is necessary before we begin.

Download the RPOW source from the download page. The 4758 server source is in the scc subdirectory. Go to that subdirectory and edit the Makefile there as follows:

Set the SCCTK_FS_ROOT variable to WD/scctk, where again WD is the working directory where you downloaded and built the tools.

Set the CC variable to WD/cross/bin/i386-linux-gnu-gcc.

Those are the only edits needed to the Makefile. Now build the memory image file: 

make rpow.rod

This should compile the source code to .o files, link to produce rpow.exe, then run the IBM tools to produce first rpow.xld and then the memory image, rpow.rod. There is a final cleanup with a short perl script to reset the creation date within the rpow.rod file to a canonical date so that it will match the version installed in the RPOW server.

The installed rpow.rod file is supplied in the installed subdirectory. Comparing the file you just built with that one should produce no output, meaning that they are identical: 

cmp rpow.rod installed/rpow.rod

If all went well, skip on to the verification section. Otherwise proceed to troubleshooting:

Troubleshooting

The most common cause of trouble is that the IBM tools are built for older Linux systems, and some of the shared libraries are no longer present in those versions on new systems. Particularly the program cpqxlt, which turns the .exe file produced by GCC into a .xld file, uses some shared libraries. I was able to fix this by putting a symbolic link into /usr/lib for the old version of libstdc++, as follows: 

cd /usr/lib
ln -s libstdc++-libc6.2-2.so.3 libstdc++-libc6.1-1.so.2
You may need to add a similar link on your Linux system if this tool complains.

If you have problems building the GCC cross compiler and tool chain, there are a number of resources on the web. The CrossGCC FAQ is a good place to start.

In case the build succeeds but the rpow.rod file doesn't match the one in the installed directory, that directory also contains the other object files which are created in the build process. Comparing the .o, rpow.exe, and rpow.xld files with those in the installed directory may give a hint as to what is going wrong. Keep in mind that object files typically include headers based on the current date, so it is not expected that these files will compare byte-for-byte identically. One possible strategy is to use hexdump to convert a file to hex format, then to compare the files in that form. This may help to distinguish insiginificant differences in the headers from more meaningful differences in the compiled code.

Verification

Congratulations! If you've gotten this far then you've successfully built the RPOW source code into an rpow.rod file that matches the one installed in the running RPOW server. Verification of this fact involves two more steps:

First, run sha1sum on the rpow.rod file you just produced, and note the hash it reports. Second, examine the source code of the RPOW client software, the connio.c module, and look at the variable seg3okhash. This should match the value output by sha1sum. Examining the client source code will show that it receives a signed data structure from the IBM 4758 which includes the hash of the running memory, and that it compares against this value in the seg3okhash variable. Only if they match will the client accept the rest of the data and save it as a valid key for communicating with.

Together, these steps imply that the source code supplied for the RPOW server produces an executable file whose hash matches that reported by the running RPOW server system. This report is signed by a key which is validated ultimately by IBM's root signing key, as described on the security page. Only a valid IBM 4758 can make such a certification, showing that this is in fact the code which is running on the RPOW server.

By further examining the RPOW server source code in the scc subdirectory, it is possible to verify that there are no back doors or loopholes and that the system will behave honestly in its simple task of issuing RPOW tokens. This verification is the foundation for the security of the RPOW system.