On 21-07-2010 21:50, Bryan wrote:
On Wed, Jul 21, 2010 at 13:19, Jakob Bohm<jb-open...@wisemo.com> wrote:
On 21-07-2010 18:26, Bryan wrote:
On Wed, Jul 21, 2010 at 10:33, Jakob Bohm<jb-open...@wisemo.com> wrote:
On 19-07-2010 16:18, Bryan wrote:
I am trying to build openssl 0.9.8o with the fips-1.2 source. I'm
building it using cygwin as the interface, since I am trying to script
this into an installation process.
When building with Visual Studio, you are better off using a perl version
itself compiled as a native program (such as Strawberry perl
or ActiveState perl), and not putting CYGWIN on your path.
Sorry, I failed to mention that I installed ActiveState Perl... and am
using it. When I run "which perl" states "/cygdrive/c/Perl/bin/perl"
which is where I installed ActivePerl.
Good.
The big problem however is that some CYGWIN binaries may have name clashes
with Microsoft binaries that do something *completely* different, leading to
nasty surprises whenever a shell (including make)
picks up the wrong one.
Well, the good thing is I am building this on an XP machine inside a
VM, and I created a snapshot before I started all this, so backing out
is an option to be able to start over and configure the environment
correctly. This might even be what I have to do, since I thought that
I'd need programs like nasm, and mingw to build it. I did a lot of
searching before I started asking questions...
The cygwin interface is using
Visual Studio 8 to build the source, using the cl.exe. After disabling
cygwin's "link.exe", I was able to build the FIPS libraries, but when
I try to build openssl with fips enabled, I receive an error.
As discussed in another recent thread about the FIPS module, it is not
really intended to be built automatically. Any deviation from the very
specific *manual* procedure in the certification documents voids the
FIPS certification, making the exercise useless.
I just joined last night. I googled for the error message before
joining, but I couldn't get a straight answer from yahoo/google that
concerned openssl/fips that was within the last few years. Mayhaps I
didn't search efficiently...
The thread did not mention your error messages as that thread was about
someone doing the same on Linux with rpms.
So you are saying that you don't build the FIPS module first? You
build OpenSSL with FIPS at the same time? We downloaded the separate
"openssl-fips-1.2.tar.gz" and build it and then build
openssl-0.9.8o.tar.gz. Back to the drawing board... I'll just back
everything out... guess we read too much into the 140-2 doc...
assumed that FIPS had to be build, and then build openssl pointing to
the FIPS lib.
No.
I am saying that the FIPS binary blob exists for only one purpose:
to satisfy the bureaucratic rules required by the FIPS certification.
Typically, the FIPS module is compiled *once* by a developer who
slavishly follows the exact bureaucratic steps in the openssl specific
FIPS certification documents, with no deviations or improvements however
sane, (not even security fixes are allowed without recertification!)
Then the resulting .o, .obj, .a or .lib file is stored away as a binary
file which will then be used every time you (automatically) build the
rest of openssl-with-fips-certified-core.
So when I build the library, I need to stuff in a directory where it
will be protected from unauthorized access, but still have enough
permissions to allow it to be accessed.
You just treat the binary blob as source code, and make sure no-one
changes it without your knowledge and consent (just like all the
other important source code).
We found the location of crypt32.lib and added that directory to the
very beginning of our $PATH, but it does not appear to be working.
Remember that with MS compilers, library directories need to be on the
path described by the environment variable "LIB", not the path
described by the environment variable "PATH"
I have no idea how MS compilers work. I am used to building using ONLY
Unix (.configure&& make&& make install). Ultimately, I have to
compile OpenSSH to create executables for windows. OpenSSL-fips is
needed for our customers.
I see a LIBPATH, and LIB when I do a "printenv" in cygwin. Can I
permanently set this in my .bashrc?
OK, here are the path-like environment variables for MS compilers and shells
(all have uppercase names and use semicolon, not colon as separator, CYGWIN
shells sometimes try to hide this).
1. PATH the path for executable programs, just like on UNIX. The current
dir (.) is always searched before PATH, even if . is also mentioned on it.
2. PATHEXT is the list of file extensions appended to command names to get
the file names of executable binaries, it is searched left to right
like other paths. The behavior if there is a file with one extension in
one directory on PATH and a file with a higher priority extension in a
lower priority directory on PATH is somewhat unspecified. Windows versions
before Windows 2000 don't use this. Some shells also ignore this.
3. LIBPATH is used only be a very few non-native programs to locate shared
libraries (DLLs). Corresponds to ld.so.conf, but only for a
few program types (such as OS/2 binaries).
4. LIB the path for .LIB files (same file format is used for static
libraries (UNIX format .a files) and import libraries (special files
telling the linker how to embed references to a dll, similar to the
.so symlinks on Linux, but with no need to have the .DLL itself
available at link time). Corresponds to
'/usr/local/lib:/usr/lib:/lib'
on UNIX.
5. INCLUDE the path for .h files etc. used by the C preprocessor,
corresponds to
'/usr/share/gcc/version/include:/usr/local/include:/usr/include'
on Linux.
PATH, LIB and INCLUDE are typically set by sourcing the "vcvars32.bat"
script in the MS compilers bin directory. E.g.
CALL "C:\whatever it is\VC\BIN\VCVARS32.BAT"
There are alternate file names for this script if you want the 64 bit
cross compiler, or settings for debug builds etc. The start menu
has menu items which open a shell and do this for you.
Gonna save that... Thanks for that bit o' info... It's almost like
Microsoft wants to make it difficult to compile source or something.
If they'd just add FIPs-enabled SSH/SSL to their OS, things would be
much easier... SSH is BSD licensed, after all...
Actually, they do include FIPS certified SSL and crypto libraries.
Under "Local Security Policy" and "Network-wide group policy" there
is an option to put Microsoft's crypto libraries in "FIPS mode" which
restricts them to certified and approved algorithms. Please refer
to the per operating system FIPS certificates listed on the US
government FIPS certification site.
The SSL code is buried in the "SSPI" API, which needs to be invoked
in an unusual way to do SSL rather than login. This is the SSL
implementation used by Internet Explorer, Outlook etc. The SSPI
functions are exported by SECURITY.DLL or SECUR32.DLL depending on the
Windows version and are almost, but not quite, the same as the IETF
standard GSSAPI (but in no way limited to Kerberos like some Linux
implementations are).
The crypto code is in "CryptoAPI" which is included in any Windows
version that has IE4 or later installed or bundled. And in CNG
(CryptoAPI Next Generation) which is in Vista and later. CryptoAPI is
in ADVAPI32.DLL and CRYPT32.DLL (depending on the function called).
CNG is in some other DLL.
I do not know of a certified Microsoft SSH implementation (they are
all about GUI stuff), but one could conceivably be built on top of
the FIPS certified CryptoAPI rather than openssl's libcrypt.
Alternatively, but more difficult to document in a GSA bidding process,
the openssl "engine" mechanism includes an optional engine which passes
all the crypto operations on to Microsoft CryptoAPI. If you can lock
it down and document it properly, this may allow you to use standard
or slightly modified openssh code with standard openssl, but this
depends if openssl really passes on *all* the crypto calls, not just
some of them.
Did you happen to build SSH as well? If you did, was it all that
difficult? We are wanting to get away from having to use a program
called "Attachmate" to automate remote linux security installs. Right
now, we use Attachmate to push updates to our Linux boxen from
windows. We'd like to save the company some coin by being able to get
rid of Attachmate.
Actually, I have not yet had an opportunity to build the FIPS module
myself and will probably be holding out for the FIPS certification of
an openssl 1.x version. And no, I don't think I ever had the pleasure
of recompiling openssh or PuTTY myself.
> ...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
