Free/Open ACE Servers?

Tsk asks: "One of the companies I work for uses ACE server for which I need a SecurID. This works fine in closed source Unix environment, however at home I have a mix of closed source unix, free unixes and Windows machines. I would like to be abe to use my SecurID at home and thus secure my network. I'm trying to do this because I have a client that only has BSD/Linux servers, who would like to implement a SecureID based solution. I did a Google search already using 'ACE server Open' and 'ACE server Free' and received no results. I'm wondering if such setup is doable, if the software to build it is available?"

I don't think this would work

[krangomatik]

As far as I know you can't do this. In order for a server to auth your token it would have to know what the token was seeded with. When you buy tokens they send you a floppy disk with a file on it that needs to be read by the server before it can authenticate your token.

OpenBSD

[Noodlenose]

What about OpenBSD?

That's RSA-S's product

[martin]

#include "I_used_to_work_for_RSA_security.h"

There's a whole gammet of copyright and patent stuff in the SecurID tokens and ACE/Servers.

This is where RSA-Security make their money and they are hardly about to open this stuff up. Yes I know the big money spinner are the tokens (you have to buy an ew one every 3 or 5 years as the battery dies after that period), but they are hardly going to open up their algorithm for inspection by 'the world at large'. IF their where a problem with the problem I don't thing they'd take take lightly to people exposing it (can we say DCMA).

Of course these things have been out there for many years and no-one has yet reverse engineering the algo and the algo has some very repected people look at it (they boought RSA a few years ago).

But there's very very little chance of you replicating this stuff with 'free' software.

Support for Linux

[steve.m]

I hope you weren't expecting someone to have somehow magically reversed engineered the server for linux.

1. it would be a cryptocracking nightmare.
2. It's illegal - RSA wouldn't allow it and would stop people from hurting their revenue stream.

And assuming someone had done it, where would you get the Tokens from. They don't come free in cereal packets....

If you dont mind spending the mony, you don't have a problem

The ACE/agent is available for Linux. See Agent Support [rsasecurity.com]. OK, so BSD isn't supported, but you could play around with the Linux compat stuff or have them all authenticate from the Linux box running ACE/client.

You will have to run an ACE/server on Windows unless they've got Solaris, HP-UX or AIX. See Server Support [rsasecurity.com]

People on slashdot seem to be obsessed with getting something for nothing. SecurID is *a really good thing* (we use it at work) - do you think that all that work by Crypto experts could be duplicated by a few spotty geeks with too much time on their hands? Get a grip.

Re:Support for Linux

[sirket]

It has got nothing to do with getting something for nothing. The ACE server software has always been a terrible kludge. It looked awful and was a nightmare to configure at times. Things have improved greatly in the 5.x series but I still think it sucks.

On top of that, I would like the software to run on something other than Windows (*shudder*) or Solaris.

Finally, the server software is _not_ RSA's big money maker. The tokens are. I have no problem buy and paying for the tokens. I do have a problem with paying for a poorly written piece of server software that does not run on the platforms I prefer to run on.

-sirket

Re:Support for Linux

[Anonymous Coward]

umm...you fucking arrogant arsehole.
spotted geeks cant duplicate it eh ?

Sample SecurID Token Emulator with Token Secret Import

We have performed some cryptoanalysis and let's just say we do have
grounds to believe that this algorithm is easily breakable.
Once again, security of the cipher should be based entirely on the
secrecy of the key, not the algorithm.

Least Significant First byte order is assumed

/* (c) 1999-3001 I.C. Wiener */

#ifdef _MSC_VER
#pragma intrinsic (_lrotr, _lrotl)
#else /* GCC or CC */
#define __int64 long long
#define __forceinline __inline__
#define _lrotr(x, n) ((((unsigned long)(x)) >> ((int) ((n) &
31))) | (((unsigned long)(x)) << ((int) ((-(n)) & 31))))
#define _lrotl(x, n) ((((unsigned long)(x)) << ((int) ((n) &
31))) | (((unsigned long)(x)) >> ((int) ((-(n)) & 31))))
#endif

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

#define ror32(x, n) _lrotr (x, n)
#define rol32(x, n) _lrotl (x, n)
#define bswap32(x) (rol32 ((unsigned long)(x), 8) & 0x00ff00ff
| ror32 ((unsigned long)(x), 8) & 0xff00ff00)

static __forceinline unsigned char ror8 (const unsigned char x, const
int n) { return (x >> (n & 7)) | (x << ((-n) & 7)); }
static __forceinline unsigned __int64 rol64 (const unsigned __int64 x,
const int n) { return (x << (n & 63)) | (x >> ((-n) & 63)); }
static __forceinline unsigned __int64 bswap64 (const unsigned __int64 x) {
unsigned long a = (unsigned long) x, b = (unsigned long) (x >> 32); return
(((unsigned __int64) bswap32 (a)) << 32) | bswap32(b); }

typedef union _OCTET
{
unsigned __int64 Q[1];
unsigned long D[2];
unsigned short W[4];
unsigned char B[8];
} OCTET;

void securid_expand_key_to_4_bit_per_byte (const OCTET source, char *target)
{
int i;

for (i = 0; i < 8; i++)
{
target[i*2 ] = source.B[i] >> 4;
target[i*2+1] = source.B[i] & 0x0F;
}
}

void securid_expand_data_to_1_bit_per_byte (const OCTET source, char
*target)
{
int i, j, k;

for (i = 0, k = 0; i < 8; i++) for (j = 7; j >= 0; j--) target[k++] =
(source.B[i] >> j) & 1;
}

void securid_reassemble_64_bit_from_64_byte (const unsigned char *source,
OCTET *target)
{
int i = 0, j, k = 0;

for (target->Q[0] = 0; i < 8; i++) for (j = 7; j >= 0; j--) target->B[i]
|= source[k++] << j;
}

void securid_permute_data (OCTET *data, const OCTET key)
{
unsigned char bit_data[128];
unsigned char hex_key[16];

unsigned long i, k, b, m, bit;
unsigned char j;
unsigned char *hkw, *permuted_bit;

memset (bit_data, 0, sizeof (bit_data));

securid_expand_data_to_1_bit_per_byte (*data, bit_data);
securid_expand_key_to_4_bit_per_byte (key, hex_key);

for (bit = 32, hkw = hex_key, m = 0; bit <= 32; hkw += 8, bit -= 32)
{
permuted_bit = bit_data + 64 + bit;
for (k = 0, b = 28; k < 8; k++, b -= 4)
{
for (j = hkw[k]; j; j--)
{
bit_data[(bit + b + m + 4) & 0x3F] = bit_data[m];
m = (m + 1) & 0x3F;
}

for (i = 0; i < 4; i++)
{
permuted_bit[b + i] |= bit_data[(bit + b + m + i) & 0x3F];
}
}
}

securid_reassemble_64_bit_from_64_byte (bit_data + 64, data);
}

void securid_do_4_rounds (OCTET *data, OCTET *key)
{
unsigned char round, i, j;
unsigned char t;

for (round = 0; round < 4; round++)
{
for (i = 0; i < 8; i++)
{
for (j = 0; j < 8; j++)
{
if ((((key->B[i] >> (j ^ 7)) ^ (data->B[0] >> 7)) & 1) != 0)
{
t = data->B[4];
data->B[4] = 100 - data->B[0];
data->B[0] = t;
}
else
{
data->B[0] = (unsigned char) (ror8 ((unsigned char)
(ror8 (data->B[0], 1) - 1), 1) - 1) ^ data->B[4];
}
data->Q[0] = bswap64 (rol64 (bswap64 (data->Q[0]), 1));
}
}
key->Q[0] ^= data->Q[0];
}
}

void securid_convert_to_decimal (OCTET *data, const OCTET key)
{
unsigned long i;
unsigned char c, hi, lo;

c = (key.B[7] & 0x0F) % 5;

for (i = 0; i < 8; i++)
{
hi = data->B[i] >> 4;
lo = data->B[i] & 0x0F;
c = (c + (key.B[i] >> 4)) % 5; if (hi > 9) data->B[i] = ((hi = (hi
- (c + 1) * 2) % 10) << 4) | lo;
c = (c + (key.B[i] & 0x0F)) % 5; if (lo > 9) data->B[i] = (lo = ((lo
- (c + 1) * 2) % 10)) | (hi << 4);
}
}

void securid_hash_data (OCTET *data, OCTET key, unsigned char
convert_to_decimal)
{
securid_permute_data (data, key); // data bits are permuted depending on
the key
securid_do_4_rounds (data, &key); // key changes as well
securid_permute_data (data, key); // final permutation is based on the
new key
if (convert_to_decimal)
securid_convert_to_decimal (data, key); // decimal conversion
depends on the key too
}

void securid_hash_time (unsigned long time, OCTET *hash, OCTET key)
{
hash->B[0] = (unsigned char) (time >> 16);
hash->B[1] = (unsigned char) (time >> 8);
hash->B[2] = (unsigned char) time;
hash->B[3] = (unsigned char) time;
hash->B[4] = (unsigned char) (time >> 16);
hash->B[5] = (unsigned char) (time >> 8);
hash->B[6] = (unsigned char) time;
hash->B[7] = (unsigned char) time;

securid_hash_data (hash, key, 1);
}

unsigned char hex (const char c)
{
unsigned char n = c - '0';

if (n < 10) return n;
n -= 7;
if ((n > 9) && (n < 16)) return n;
n -= 32;
if ((n > 9) && (n < 16)) return n;
exit (17);
}

unsigned char read_line (FILE *fi, OCTET *outb)
{
unsigned char n;
unsigned long i;
char ins[80], *s;

if (!fgets (ins, sizeof (ins), fi)) return -1;
s = ins;
if (*s == '#') s++;
if (strncmp (ins, "0000:", 5) == 0) return -1;
for (i = 0; i < 38; i++)
{
n = hex (*s++) << 4;
n |= hex (*s++);
outb->B[i] = n;
}

// securid bullshit import file decryption (how much do they pay their
programmers???)
// anyway, I replaced their 16 stupid xor-D69E36D2/rol-1 "rounds" with
one rol-16/xor
// doing exactly the same thing (I wonder what they used to generate
their token secrets? ;)

// btw, we ignore the last two bytes that are just a silly checksum

for (i = 0; i < 9; i++) outb->D[i] = rol32 (outb->D[i], 16) ^
0x88BF88BF;
return 0;
}

int main (int argc, char **argv)
{
signed long i, j, k, t, serial;
OCTET key, hi, hj, input, data[5];
FILE *fi;
char *s;

if (argc != 4)
{
printf ("usage: securid <tokenfile.asc> <serial number> <current
number displayed on the token>\n");
}

fi = fopen (argv[1], "rt");
serial = bswap32 (strtoul (argv[2], &s, 16)); // although it's base-16,
it's still just a decimal number
input.D[0] = strtoul (argv[3], &s, 16); // although it's base-16, it's
still just a decimal number as well

if (!fi)
{
printf ("Cannot open token secret file.\n");
return -1;
}
for (;;)
{
if (read_line (fi, data)) return 1;
j = data->D[1]; // printf ("%08X\n", j);
if (read_line (fi, data)) return 1;
if (j == serial)
{
key.Q[0] = data->Q[0];
break;
}
}
fclose (fi);

if (j != serial)
{
printf ("Token not found.\n");
return -1;
}

t = (time (NULL) / 60 - 0x806880) * 2; // (t & -4) for 60 sec periods,
(t & -8) for 120 sec periods, etc.

for (i = (t & -4), j = (t & -4) - 4; i < (t & -4) + 0x40560; i += 4, j
-= 4)
{
securid_hash_time (i, &hi, key);
securid_hash_time (j, &hj, key);
if ((hi.B[0] == input.B[2]) && (hi.B[1] == input.B[1]) && (hi.B[2]
== input.B[0]))
{
j = i; k = (i - (t & -4)) / 2; break;
} else if ((hi.B[3] == input.B[2]) && (hi.B[4] == input.B[1]) &&
(hi.B[5] == input.B[0]))
{
j = i; k = (i - (t & -4)) / 2 + 1; break;
} else if ((hj.B[0] == input.B[2]) && (hj.B[1] == input.B[1]) &&
(hj.B[2] == input.B[0]))
{
i = j; k = (j - (t & -4)) / 2; break;
} else if ((hj.B[3] == input.B[2]) && (hj.B[4] == input.B[1]) &&
(hj.B[5] == input.B[0]))
{
i = j; k = (j - (t & -4)) / 2 + 1; break;
}
}
if (i != j)
{
printf ("Either your clock is off by more than 1 year or invalid
token secret file.\n");
return -1;
}
if (k)
{
printf ("\nToken is %s your clock by %d minute%s.\n\n", (k > 0) ?
"ahead of" : "behind", abs (k), (abs (k) == 1) ? "" : "s");
}
else
{
printf ("\nToken clock is synchronised with yours.\n\n");
}
for (j = 0; j < 40; j += 4)
{
securid_hash_time (i + j, &hi, key);
printf ("%X : %02X%02X%02X\n", i + j, hi.B[0], hi.B[1], hi.B[2]);
printf ("%X : %02X%02X%02X\n", i + j, hi.B[3], hi.B[4], hi.B[5]);
}
printf ("\nOK\n");
return 0;
}

P.S.
To the folks at RSA: if you need help with designing secure
encryption
algorithms and protocols, let us know, we'll help you out. We're not
all bears here in Russia. We play chess better than you, remember?
P.P.S.
greets 2all from D.M0ecus

SecurID security legends.

[Nonesuch]

All of the known attacks against SecurID are based on either stealing the secrets from the ACE/Server or from a software client.

If you deploy the SecurID hardware tokens, extracting the key from a token is a difficult and destructive process. No uber-hacker is going to be able to take a quick glance at the display on a key fob (or the serial number on the back) and then turn around and break into your systems five minutes later.

If you are feeling really paranoid, you can talk SecurID into selling you the "PINpad" hardware token.

RSA Hardware product line: http://www.rsasecurity.com/products/securid/hardwa re_token.html [rsasecurity.com]

Re:Support for Linux

[WH]

I was at a conference 2 or 3 years ago and was shown a hacked secureID that had the ability to clone other secureID's.

Personally I think secureID gives people a false sense of security and I'd rather use something like the DES gold cards.

Best bet is to piggy back

[Jon Peterson]

Hi,

As others have said, ACE/SecurID is basically closed source software. If they don't release it for a given platform, you're stuck.

However, bear in mind it's effectively a client/server type system. The server end (the database) has limited platform support, but the clients (or agents as RSA call them) are pretty widely available.

Even so, you are right in that I don't think there are agents for many free unixes. Your best bet is probably to create your own 'agent' that basically forward the PIN/passcode combo to a box running the SecurID API (yes, they do have an agent API (or did circa 1999)), and then sends back an 'OK' or 'notOK'. Of course the insecurity of this proxying mechanism is another issue.

Another possibility is to run iPlanet on a commercial unix, together with the SecurID plugin for it. You could then write your own 'agent' that made HTTP requests with the passcode/PIN and authenticated against the iPlanet plugin (which in turn authenticates against the ACE server of your choice).

Anyway, I did a load of SecurID stuff a few years ago, and even got 90% through writing a Perl API ontop of their C API. The product then was pretty stable and basically worked well, and the API worked too.

wake up

[johnjones]

err

why use this stuff when I can offer the CEO's secetry $10k in cash and get any information I want
on top of this you pay for this and you dont know whats inside !

so how do you prove its secure ?

hell you trust software companys more than I ever will
(for this level of stupidness you must pay)

regards

john jones

How do you prove ANYTHING is secure?

[Nonesuch]

why use this stuff when I can offer the CEO's secetry $10k in cash and get any information I want...

Part of the reasoning behind any "hardware authentication token" deployment is usually to generate a strong audit trail. If sensitive records are accessed with the CEO's token, then the timestamped record of who generated the report is going to be available if we later determine there is an exposure.

Unlike a password, the hardware token cannot be shared/cloned/copied without destroying the original.

In many enterprises and government agencies, security is not only in place to control access, but to provide a reliable record of who accessed what, when. Accountants go wild for that stuff.

In my case, on the systems I have access to (including the authentication server), no C** executives have direct access to the server. There are three people who can run reports. In theory, if we all died from Ebola then somebody could obtain access to the data center (no easy task), and use physical access to the critical servers to extract the data directly from the drives (boot CD, etc).

Yes, the CEO, CTO, or the directors of Finance or HR can request that we generate specific reports, and can conceivably ask for any/all of the computer records, but any such request creates a paper trail. I do about 5 reports a year from my records, usually after an incident that might make the news, if only as a 15-second sound bite.

So yes, you might be able to bribe a secretary with $10K to hand over the records, but when the leak is discovered, the threat of 10 years in prison will work just as well to convince her to hand over your name.

so how do you prove its secure ?

How do you prove anything is secure? At some point you have to trust somebody. In the case of authentication services, you look for outside review from experts (under NDA regarding technical details) and then do your own testing for functionality, reliability, and security.

Anything less is irresponsible. Anything more is a waste of time and money.

I have no illusions about my own importance. I'm just a gatekeeper... none of the data I work with has any impact on National Security, and exposure of the data I maintain is never a life-or-death matter. We could do a less thorough job, and the worst case scenario might be a half-billion dollar loss. No big deal, right?

It is do-able technically...

[turambar386]

The algorithm was posted last year to Bugtraq by a Russian who decompiled one of the PalmPilot software tokens. Therefore it is technically possible to create your own ACE clone server.

However, I'm sure that if you tried to distribute it that RSA would come after you with a big stick.

Your real practical problem, however, is that even if you coded a clone authentication server, you need the seed for your particular token in order to make it work. Unless you are good friends with the ACE administrator at your work, this is unlikely to happen.

Re:It is do-able technically...

[Nonesuch]

turambar386 writes:

Therefore it is technically possible to create your own ACE clone server.

However, I'm sure that if you tried to distribute it that RSA would come after you with a big stick.

You hit the nail on the head.

Yes, it is technically possible. But it would take a lot of work, and all you would get for your effort is civil/criminal persecution from RSA.

RSA/SecurID has a lock on the "time synchronous" authentication token. But aside from some ease of use issues, time sync isn't really the best way to do authentication tokens. There are plenty of free open source and less-expensive commercial implementations of "event synchronous" tokens (SafeWord, CryptoCard, Axent, etc) to choose from.

Your real practical problem, however, is that even if you coded a clone authentication server, you need the seed for your particular token in order to make it work. Unless you are good friends with the ACE administrator at your work, this is unlikely to happen.

And if he did give you the seed, he should be fired.

The seed is not only sufficient information for you to clone the token into your server, but, in combination with the PIN, would provide enough information for a hacker to log into your employer's server as you.

This would not be true of a "public key" crypto system, but basically, SecurID is a 'shared secret' system, with one copy of the secret stored in the server, and the other copy embedded into your hardware token or encrypted in the software token.

If you can obtain a copy of the shared secret (for example, the various known attacks against the software token), the token is compromised. The hardware tokens do a reasonably good job of protecting the secret.

Use S/Key for your home network

[kriston]

Part of SecurID's security is that you need RSA to create the seed for you unless you can copy that seed for your home network and use it there. Since this is your own home network anyway, use S/Key instead for a similar one-time pad security solution:
http://www.ece.nwu.edu/CSEL/skey/skey_eecs.html [nwu.edu]

Kris

S/Key is now OPIE, & built into *BSD, other Un

[Nonesuch]

When deploying a S/Key derived OTP, you will want to take care in the selection of crypto algorithms. The original MD4 S/Key implementation has serious known weaknesses. MD5 is suspect.

The paranoid admin will deploy OPIE with SHA1 or RIPEMD-160, but there are very few clients/servers with support for anything beyond MD5.

• http://inner.net/opie [inner.net]
• http://original.killa.net/infosec/otpCalc/ [killa.net]
• http://palmkey.sourceforge.net/ [sourceforge.net]
• http://directory.google.com/Top/Computers/Security /Authentication/One_Time_Passwords/ [google.com]

Here's the scoop on the name change:

"One-time Passwords In Everything" (OPIE) is a freely distributable software package originally developed at and for the US Naval Research Laboratory (NRL). Recent versions are the result of a cooperative effort between of NRL, several of the original NRL authors, The Inner Net, and many other contributors from the Internet community.

OPIE is an implementation of the One-Time Password (OTP) System that is being considered for the Internet standards-track. OPIE provides a one-time password system. The system should be secure against the passive attacks now commonplace on the Internet (see RFC 1704 for more details). The system is vulnerable to active dictionary attacks, though these are not widespread at present and can be detected through proper use of system audit software.

OPIE is primarily written for UNIX-like operating systems, but work is underway to make applicable portions portable to other operating systems. The OPIE software is derived in part from and is fully interoperable with the Bell Communications Research (Bellcore) S/Key Release 1 software. Because Bellcore claims "S/Key" as a trademark for their software, NRL was forced to use a different name (they picked "OPIE") for this software distribution.

The "primary" OPIE site is http://inner.net/opie [inner.net]

Not a free, but CryptoCard is an option

[mrroach]

I am using Cryptocard on a debian server. They use a mysql backend and their own radius server for the actual authentication. The client is java so I can manage it from my debian workstation as well. It was pricy ($10,000 for 250 users) but far less expensive than RSA's equivalent solution.

Only need "closed" OS box for server, not clients

[Nonesuch]

The ACE/Server software application runs on Windows NT or Solaris. It includes a proprietary database, license key validation, and the "secret" SecurID hash algorithm. I can't see any of these components being open-sourced.

You need one or two servers, then your clients can be just about any operating system. SecurID offers ACE agents for a number of platforms, or you can use RADIUS authentication.

There are PAM modules to do RADIUS authentication for every free/commercial Unix I've tried.

proprietary database = Progress database

[Erik_]

..includes a proprietary database. To me it looks a lot like the Progress database.

RSA SecurID Algorithm

[turambar386]

I didn't have time earlier, but for those interested, here [securityfocus.com] is the original Bugtraq post by 'I.C. Weiner' (those Russians are so funny.. and modest too!) detailing the RSA SecurID Algorithm.

And for those really interested in the topic, here [securityfocus.com] is Vin McLellan's excellent response detailing why publication of the algorithm does nothing to hurt the security of the system.

One last thing.. some people are saying that ACE will only run on Windows or Solaris. According to my ACE/Server 5.0 Install Guide for UNIX, it is also supported on AIX and HP-UX. The Guide also seems to suggest that it may run on other unices, but would not be supported by RSA.