Free/Open ACE Servers? 25
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 (Score:3, Informative)
OpenBSD (Score:1)
That's RSA-S's product (Score:4, Informative)
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 (Score:3, Insightful)
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 (Score:2)
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 (Score:2, Informative)
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
#ifdef _MSC_VER
#pragma intrinsic (_lrotr, _lrotl)
#else
#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);
the key
securid_do_4_rounds (data, &key);
securid_permute_data (data, key);
new key
if (convert_to_decimal)
securid_convert_to_decimal (data, key);
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;
}
programmers???)
one rol-16/xor
their token secrets?
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));
it's still just a decimal number
input.D[0] = strtoul (argv[3], &s, 16);
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];
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 & -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. (Score:2)
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 (Score:1)
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 (Score:2)
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 (Score:4, Insightful)
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? (Score:2)
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.
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... (Score:2, Interesting)
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... (Score:1)
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.
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 (Score:2, Interesting)
http://www.ece.nwu.edu/CSEL/skey/skey_eecs.html [nwu.edu]
Kris
S/Key is now OPIE, & built into *BSD, other Un (Score:3, Informative)
The paranoid admin will deploy OPIE with SHA1 or RIPEMD-160, but there are very few clients/servers with support for anything beyond MD5.
Here's the scoop on the name change:
The "primary" OPIE site is http://inner.net/opie [inner.net]Not a free, but CryptoCard is an option (Score:1)
Only need "closed" OS box for server, not clients (Score:2)
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 (Score:1)
RSA SecurID Algorithm (Score:2, Interesting)
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.