RE: build openSSL for an embedded system without an OS
Ger, thank you for this response. I really do just need the RSA decryption bits, so I think that the approach you recommend is far too heavy-handed for me. I will check out the rsaref and cryptlib that you mentioned! -Greg -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ger Hobbelt Sent: Tuesday, February 17, 2009 8:40 PM To: openssl-users@openssl.org Subject: Re: build openSSL for an embedded system without an OS I've done this sort of thing back before 2000. I'd label my approach back then as 'force brutish' as it was a mix of using the build system and some code changes. The trick is to search the configure system for a *hardware* (CPU!) which is identical or at least very similar to your embedded one. Do an initial cross-compile and expect lost of trouble along the way, but that's okay. TIP for memoryspace-challenged systems (such as embedded systems): check out all the noxyz options in the configure script (and grep for the OPENSSL_NO.* #defines which are thus set up this way) to ensure you already have a minimal sized build. You may need to add extra #defines to cut out more bits of OpenSSL code when the space is really really tight in there, but that need was much bigger back in Y2K as OpenSSL had fewer sections that way than it has today. The next part of the trick was twofold: I wrote a shell script which find/grep-ped the source tree and sed-ed all the system header files in there according to a sed script I set up. After all, few embedded boxes like that have such headers as unixstd.h (obviously), but you will find on embedded systems like that, which often lack a RTL or only a minimal subset, that you'll have to 'treat' all the system #includes. So I wrapped them in conditional compilation code (IIRC) and then made sure the embedded system-targeting makefiles would include that #define in the compiler invocation. Then the other part is concocting a posix-like RTL API + implementation of your own: for example, OpenSSL uses the FILE stream I/O API (fopen/fread/fclose/etc.) in some places, so you'll have - when you need those bits - to 'roll your own', e.g. by writing those functions which address a memory area in Flash memory instead, for example. It is highly dependent on your embedded system, after all. When you are 'clean' about it, you might want to add your own supported systems in the configure platform tables. This then becomes an iterative process, where you re-run configure, check linker reports for missing system APIs demanded by OpenSSL and meanwhile check you've got the bits that are important to you and none of the rest. And any which way I turn this: as long as your embedded systems are not supported in the official distro, you'll always have some sort of merging to do. I 'solved' this by creating a combo of a UNIX diff/patch file for the internal tweaks and a automated script which would do all the heavy munching of those system header file #includes and other 'generic / system' bits in the code tree. The added bonus of that was that it was 'export safe' at the same time as there wasn't a single line of crypto in the kit. My project was based on the (useful) assumption that this code would always be *cross-compiled* from a Unix host system, so awk, sh and such were fine. This was commercial work and the NDA never got lifted, so I can't share the code, even if I could, but I hope you now have a good idea about how one could do this. One style. It has been done, and it worked, for several embedded embedded platforms, including ARM. The company I did this for was EbsNet (EtcBin) : http://www.ebsnetinc.com/software-documents.php?id=66 I haven't kept track really, so I don't know if they still use my work of old as a base for their current product as it seems they've MSWin stuff in there as well now. Heck, it's been 9 years. Or was it 10? Anyway, despite you say you don't need the SSL part, they always offered full source code as part of their products, so you might want to ask them about it. I know they already supported ARM back then, so I would be amazed when they'd not have that anymore. Often paying for [part of] the work that way may be cheaper than you doing the exercise all over again yourself. (And yes, I am aware they offer an SSL stack, but if it still is OpenSSL-based, they VERY probably have the option to cut out the SSL part entirely and thus have you compile only the RSA bits.) Now that I checked their site, I see almost all the folks I worked with back then are on the about page photograph. Nice bunch, very friendly. Loved being there. (Since you picked OpenSSL as your starting point, I assumed a few things. When you just want RSA code and no particulars about it, there is the old rsaref code around on the net and then there's the various crypto libraries, i.e. the ones _without_ SSL, such as cryptlib (from Peter Gutmann IIRC). Me, I'm an OpenSSL adept, so I don't bother
Re: build openSSL for an embedded system without an OS
On Wed, Feb 18, 2009 at 4:24 PM, Guyotte, Greg gguyo...@ti.com wrote: Ger, thank you for this response. I really do just need the RSA decryption bits, so I think that the approach you recommend is far too heavy-handed for me. I will check out the rsaref and cryptlib that you mentioned! All right. Since you don't need anything more than just that, I think that indeed is the smarter move now. Good luck! -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: build openSSL for an embedded system without an OS
Hello, owner-openssl-us...@openssl.org wrote on 02/18/2009 07:17:51 PM: On Wed, Feb 18, 2009 at 4:24 PM, Guyotte, Greg gguyo...@ti.com wrote: Ger, thank you for this response. I really do just need the RSA decryption bits, so I think that the approach you recommend is far too heavy-handed for me. I will check out the rsaref and cryptlib that you mentioned! All right. Since you don't need anything more than just that, I think that indeed is the smarter move now. Sorry for response to this email but I do not have earlier posts. If you want RSA decryption routine then you may try to extract from OpenSSL some BIGNUM files, probably: bn_add.c bn_asm.c (probably may be removed - depend on your platform) bn_ctx.c bn_div.c bn_exp.c bn_gcd.c bn_lcl.h bn_lib.c bn_mod.c bn_mont.c bn_mul.c bn_recp.c bn_shift.c bn_sqr.c bn_word.c cryptlib.h and compile this to library format. Of course some modification will be needed. With BN library you need only RSA decryption routine which you can borrow from file: rsa_eay.c Depending on decryption scheme you may need RSA_eay_public_decrypt() or RSA_eay_private_decrypt(). If you will need RSA_eay_public_decrypt() some BN files needed for Montgomery method may are not required (bn_mont.c). The most complicated part is to properly define header files depending on you platform architecture (8bit/16bit/32bit). Best regards, -- Marek Marcola marek.marc...@malkom.pl __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where is the EVP_CIPHER defined?
2009/2/18 Ger Hobbelt g...@hobbelt.com
On Tue, Feb 17, 2009 at 12:49 PM, sofian sindhi sofiansis...@gmail.com
wrote:
Dear all:
I trace openssl recently and I cannot find where the location of
EVP_CIPHERs
defined in evp.h.
In evp.h, it is declared as const EVP_CIPHER *EVP_camellia_128_ecb(void);
But where is the trully EVP_camellia_128_ecb(void) located?
I have grepped the source but I cannot get any hint.
In your question you are mixing up two things: EVP_CIPHER is a data
structure type (used to carry around cipher context needed by the user
the cipher to perform the task in multiple phases while the data is
fed piecemeal to the system at the same time).
grep EVP_CIPHER --
ossl_typ.h:
typedef struct evp_cipher_st EVP_CIPHER;
-- grep struct evp_cipher_st --
evp.h:
struct evp_cipher_st { .. };
(which, incidentally, also has /* EVP_CIPHER */ as a comment/hint at
the end, so we are heartened in knowing we've hit the jackpot there)
When, instead, you want to find where the _function_
EVP_camellia_128_ecb() is defined in the code, and, as you found,
cannot track it's definition down using grep (regular text search),
then you can go about it various ways, but the oldest and most sure
way is this:
when you are in such a situation (and otherwise ;-) ), remember that
'C' also comes with a *preprocessor*.
That one is used to conditionally include / exclude chunks of source
code at compile time, but also offers 'macro' functionality, which in
the 'C' realm, can be used to implement something similar to
'templates' (as we know them in, for example, 'C++'. FYI: OpenSSL
uses this possibility to great effect in various spots (EVP ASN1
most particularly).
Nothing fancy or difficult, it's just that people tend to forget or,
more often, never got taught the language properly (and then complain
about others' lack of minding their forgetfulness :-) ). No worries,
it's just got to be my Grumpy Day today. ;-)
So, can't find a function or data definition anywhere?
Here's the general process of digging them up:
Run the code through the *preprocessor* and then have a grep through
that (intermediate) output. (After all, all the preprocessor does is
munch source code and spit out 'preprocessed' *source code* for the
actual *compiler*.
(Almost) all compilers (and at least ALL the ones I've met in
non-embedded environments) offer an option to do exactly that:
generally, this is command line option '-E' (~ 'execute preprocessing
phase only').
for example:
gcc has '-E'
MSVC cl has '-E' and '-EP'
the hard(er) part is getting the '-E' option added to your compiler
commandline argument set (easy on most systems by temporarily
redefining GCC or CC environment args so that
CC='gcc -E'
instead of
CC='gcc'
but this can cause some trouble in your makefiles as they won't expect
this, but alas, you're interested in preprocessed sourcecode there
now, not working executables, so ignore the alarm bells and let it
rip.
Most systems will write such -E preprocessed output to either a .i
file (sourcefilename.i, e.g. apps.c -- apps.i) or the .o or .obj
file if such a target was specified explicitly on the commandline
using '-o'. There's no 'always so' rule to this bit, hence me saying
it's 'harder', meaning: you must check how it acts on your system and
environment, whichever it is.
The alternative is running your suspects through 'gcc -E' or your
local equivalent *by hand*. ( = copypaste commandlines issued from
make, add the -E yourself and have a go.)
The second alternative, when '-E' is not available or otherwise
unwilling to cooperate, is to trace the code using a source-viewing
debugger: as you run through the code you will notice that function
calls will instead sometimes show macro invocations outside any
function scope. That's a sure sign there's some templating / code
generation going on under the hood right there.
-- from there, find those macro definitions and inspect their source
code. Further drilldown takes a tool like grep again.
So far, Preprocessor Ed 102. (Giving you just the result is pretty
useless; the above is needed to enable you to reproduce the result and
answer subsequent, similar questions on your own.)
The result of this search will find you EVP_camellia_128_ecb() here:
evp_locl.h:
const EVP_CIPHER *EVP_##cname##_##mode(void) { return cname##_##mode; }
which is a function returning the static/const structure defining the
cipher and its requirements, such as block length, IV size, ASN.1
aspects such as object ID (nid), plus: the functions (in object/class
oriented terms that would be 'methods' rather) used to perform the
action on chunks of data (cname##_##mode##_cipher), cleanup the
EVP_CIPHER object when you're done (cleanup), etc.
When you follow the preprocessor (i.e. answer the question: how did
this bit get expanded into that EVP_camellia_128_ecb() we were looking
for?), you'll find it starts
