Yubico Forum
https://forum.yubico.com/

problems with reprogrammed yubikeys: BAD_OTP
https://forum.yubico.com/viewtopic.php?f=3&t=208		 Page 1 of 1
Author:  rbd [ Thu Nov 20, 2008 6:53 pm ]
Post subject:  problems with reprogrammed yubikeys: BAD_OTP
Hi guys,

I'm evaluating Yubikeys for our organization. The price is right, and we use open source widely so it fits right in there. However I must say that we've been a bit....disappointed on the software and documentation side....on pushing Yubikeys into organizations, the whole thing still seems to be in a very early phase (seems like it's written by programmers for programmers :). Besides that the solution looks very simple and very solid. I think that once all of this is done I can contribute a guide to how we got it all set up (if that does happen :cry: )....

Which leads me to the problem. We've set up a server, installed Ubuntu 8.10, Apache2, php5, yubiphpbase, pubico-php-lib, the php webservices and the YMS. The docs were a bit confusing but I think we got this figured out.

So next, we downloaded the personalization utility, and tried using it (used both the MFC version and the HTML version). It took some time to figure out what was what, but the included PDF was somewhat helpful (not nearly enough examples). For the static ID and UID we used the device ID of the key converted into hex ("9725b3ed678e", we also tried with a randomly generated hex number...as the docs made it seem like either would work). Then we entered in a generated AES key ("c7038b85de5f8bc0760c016741e3a23d"). We had debugging on and everything looked good. We pressed the ykProgram button and got the text "Program completed. Kill=0, rc=0". Looking at the code, RC of 0 looks like the OK code. So it looks like the reprogramming went through (at the very least, changes to the flags seemed to stick).

So, next we had to hack YMS a bit as it had "api.yubico.com" hardcoded a few places, etc. Once that was done, we go to our OTP server web service: http://otp.corp.XXXX.XXX/wsapi/verify_d ... bvcntcigdg

After I added some custom debug printouts, we get the following:
Code:
<p>Debug> aes key in modhex = ienteivbnvekiguugvvbniefuvltbrtegunnueginihnhttt
<p>Debug> aes key in hex = [s½7ñ¿9uî_ñ·4ï­Ó^»ãW·kmÝ], length = 24  <<<MY NOTE: This isn't hex...typo? We enabled this debug print in the code.>>>
<p>Debug> From the OTP validation request:
array(10) {
  ["public_id"]=>
  string(12) "kidgneuthiju"
  ["token"]=>
  string(32) "7735f9a3ca8fe3862bc18afba91ef0c3"
  ["private_id"]=>
  string(12) "7735f9a3ca8f"
  ["session_counter"]=>
  int(34531)
  ["low"]=>
  int(49451)
  ["high"]=>
  int(138)
  ["session_use"]=>
  int(251)
  ["crc"]=>
  int(50160)
  ["timestamp"]=>
  int(9093419)
  ["counter"]=>
  int(8840187)
}
<p>Debug> decoded array:

<p>Debug> 2
status=BAD_OTP
info=kidgneuthijulgrhkveidkcnrcncgtbcdubvcntcigdg
t=2008-11-20T17:27:27Z0
<p>Debug> SIGN: info=kidgneuthijulgrhkveidkcnrcncgtbcdubvcntcigdg&status=BAD_OTP&t=2008-11-20T17:27:27Z0
h=kX+T2pOMHOaQKQ5wzAoRtazeZew=


Ok so it looked like things failed at CRC validation.

Not really sure what is going on here. If the key was reprogrammed correctly this should work. I believe we entered in everything correctly into the DB when setting up the yubiphpbase library. Here's what we have:

After running util.php:

root@otpauth1:/var/www/yubiphpbase# php utils.php

Code:
API Key: nox8sOeQ/IbfiX+qX60yT/k6lyk=
PIN: 2323, Encrypted PIN: b6CsxYb7CGrVkLagsglQlA==
TokenID (b64-encoded): lyWz7WeO
PIN: 2323


Here's our dump of the database:

Code:
-- MySQL dump 10.11
--
-- Host: localhost    Database: yubico
-- ------------------------------------------------------
-- Server version       5.0.67-0ubuntu6

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `admin`
--

DROP TABLE IF EXISTS `admin`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `admin` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `keyid` int(11) NOT NULL default '0',
  `note` varchar(45) default NULL,
  `pin` varchar(120) default NULL,
  `last_access` datetime default NULL,
  `ip` varchar(45) default NULL,
  `creation` datetime default NULL,
  `client` int(11) NOT NULL default '0',
  `timeout` int(10) unsigned NOT NULL default '3600',
  PRIMARY KEY  (`id`),
  KEY `FK_admin_2` (`keyid`),
  KEY `FK_admin_1` (`client`),
  CONSTRAINT `FK_admin_1` FOREIGN KEY (`client`) REFERENCES `clients` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `FK_admin_2` FOREIGN KEY (`keyid`) REFERENCES `yubikeys` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=33 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

--
-- Dumping data for table `admin`
--

LOCK TABLES `admin` WRITE;
/*!40000 ALTER TABLE `admin` DISABLE KEYS */;
INSERT INTO `admin` VALUES (1,1,'Root Key','b6CsxYb7CGrVkLagsglQlA==','2008-08-07 21:27:51','192.168.1.100','2008-08-07 21:27:51',1,3600);
/*!40000 ALTER TABLE `admin` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `buyers`
--

DROP TABLE IF EXISTS `buyers`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `buyers` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `email` varchar(100) default NULL,
  `created` datetime default NULL,
  `addr` varchar(200) default NULL,
  `qty` int(10) unsigned default NULL,
  `client_id` int(11) NOT NULL default '0',
  `name` varchar(45) default NULL,
  PRIMARY KEY  (`id`),
  KEY `FK_client_id_1` USING BTREE (`client_id`),
  CONSTRAINT `FK_client_info_1` FOREIGN KEY (`client_id`) REFERENCES `clients` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=2201 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

--
-- Dumping data for table `buyers`
--

LOCK TABLES `buyers` WRITE;
/*!40000 ALTER TABLE `buyers` DISABLE KEYS */;
/*!40000 ALTER TABLE `buyers` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `clients`
--

DROP TABLE IF EXISTS `clients`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `clients` (
  `id` int(11) NOT NULL auto_increment,
  `perm_id` int(11) default NULL,
  `active` tinyint(1) default NULL,
  `created` datetime NOT NULL default '0000-00-00 00:00:00',
  `email` varchar(255) NOT NULL default '',
  `secret` varchar(60) NOT NULL default '',
  `notes` varchar(100) default NULL,
  `chk_sig` tinyint(1) NOT NULL default '0',
  `chk_owner` tinyint(1) NOT NULL default '0',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `email` (`email`),
  KEY `perm_id` (`perm_id`),
  CONSTRAINT `clients_ibfk_1` FOREIGN KEY (`perm_id`) REFERENCES `perms` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1678 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

--
-- Dumping data for table `clients`
--

LOCK TABLES `clients` WRITE;
/*!40000 ALTER TABLE `clients` DISABLE KEYS */;
INSERT INTO `clients` VALUES (1,1,1,'1970-01-01 00:00:00','robbyd@corp.XXXX.XXX','xzRQUxLdkjnJrJ8ycHsT1/OEjXw=','Robby Dermody',0,0);
/*!40000 ALTER TABLE `clients` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `history`
--

DROP TABLE IF EXISTS `history`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `history` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `usrid` int(10) unsigned NOT NULL default '0',
  `note` varchar(45) NOT NULL default '',
  `ip` varchar(45) NOT NULL default '',
  `creation` datetime NOT NULL default '0000-00-00 00:00:00',
  `keyid` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `FK_hist_1` (`usrid`)
) ENGINE=InnoDB AUTO_INCREMENT=347 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

--
-- Dumping data for table `history`
--

LOCK TABLES `history` WRITE;
/*!40000 ALTER TABLE `history` DISABLE KEYS */;
/*!40000 ALTER TABLE `history` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `perms`
--

DROP TABLE IF EXISTS `perms`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `perms` (
  `id` int(11) NOT NULL auto_increment,
  `verify_otp` tinyint(1) default '0',
  `add_clients` tinyint(1) default '0',
  `delete_clients` tinyint(1) default '0',
  `add_keys` tinyint(1) default '0',
  `delete_keys` tinyint(1) default '0',
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

--
-- Dumping data for table `perms`
--

LOCK TABLES `perms` WRITE;
/*!40000 ALTER TABLE `perms` DISABLE KEYS */;
INSERT INTO `perms` VALUES (1,1,1,1,1,1),(2,1,0,0,1,1),(3,1,0,0,0,0);
/*!40000 ALTER TABLE `perms` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `yubikeys`
--

DROP TABLE IF EXISTS `yubikeys`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `yubikeys` (
  `id` int(11) NOT NULL auto_increment,
  `client_id` int(11) NOT NULL default '0',
  `active` tinyint(1) default NULL,
  `created` datetime NOT NULL default '0000-00-00 00:00:00',
  `accessed` datetime default NULL,
  `tokenId` varchar(60) character set latin1 collate latin1_bin default NULL,
  `userId` varchar(60) NOT NULL default '',
  `secret` varchar(60) NOT NULL default '',
  `counter` int(11) default NULL,
  `low` int(11) default NULL,
  `high` int(11) default NULL,
  `notes` varchar(100) default NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `userId` (`userId`),
  UNIQUE KEY `tokenId` (`tokenId`),
  KEY `client_id` (`client_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4541 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

--
-- Dumping data for table `yubikeys`
--

LOCK TABLES `yubikeys` WRITE;
/*!40000 ALTER TABLE `yubikeys` DISABLE KEYS */;
INSERT INTO `yubikeys` VALUES (1,1,1,'2008-10-03 16:11:50','2008-10-22 22:08:18','lyWz7WeO','hX+j1RaP','c7038b85de5f8bc0760c016741e3a23d',0,0,0,'Robby Dermody');
/*!40000 ALTER TABLE `yubikeys` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2008-11-20 17:46:16



Any help would be GREATLY appreciated. We'd really like to start using Yubikeys.

Robby
Author:  network-marvels [ Mon Nov 24, 2008 3:22 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
We are working on a new version of the personalization tool which is scheduled to be released by mid next week that will probably make it easier to program the YubiKeys. We will test the exact configuration and will update you asap.
Author:  Simon [ Thu Nov 27, 2008 12:03 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
This looks like a rather low-level problem and possibly an incorrect AES key? Try using our command line tools to decrypt OTPs:

http://code.google.com/p/yubico-c/

/Simon
Author:  bert64 [ Tue Dec 09, 2008 3:46 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
I have a very similar problem....

ykdebug says:

$ ./ykdebug uubgvivdgkuebejhkhtjuufrebjvftrc hbhdhehfhghhlbhctufkdbkglclthjrdrhvnvvhnlhbu
warning: overlong token, ignoring prefix: hbhdhehfhghh
Input:
token: lbhctufkdbkglclthjrdrhvnvvhnlhbu
a1 60 de 49 21 95 a0 ad 68 c2 c6 fb ff 6b a6 1e
aeskey: uubgvivdgkuebejhkhtjuufrebjvftrc
ee 15 f7 f2 59 e3 13 86 96 d8 ee 4c 31 8f 4d c0
Output:
61 62 63 64 65 66 01 00 c9 68 ce 01 48 74 41 98

Struct:
uid: 61 62 63 64 65 66
counter: 1 (0x0001)
timestamp (low): 26825 (0x68c9)
timestamp (high): 206 (0xce)
session use: 1 (0x01)
random: 29768 (0x7448)
crc: 38977 (0x9841)

Derived:
cleaned counter: 1 (0x0001)
modhex uid: hbhdhehfhghh
triggered by caps lock: no
crc: F0B8
crc check: ok

so everything seems ok from ykdebug....
yubikey-val-server/validate_debug.php says:

<p>Debug> OTP validation req:
Sess ctr=56262
TS lo=64964
TS hi=32
Use=158
Rand=41782
CRC=62650
Timestamp=2162116
Calculated CRC=50232
Bad CRC
<p>Debug> 2
status=BAD_OTP
info=hbhdhehfhghhlbhctufkdbkglclthjrdrhvnvvhnlhbu
t=2008-12-09T14:44:27
<p>Debug> SIGN: info=hbhdhehfhghhlbhctufkdbkglclthjrdrhvnvvhnlhbu&status=BAD_OTP&t=2008-12-09T14:44:27
h=WdW8Fxj9u7a3SAFfDyAICGS+ADQ=

So seems to be a CRC error...

The database contains:

mysql> select * from clients;
+----+---------+--------+---------------------+------------------+--------------------------+-------+---------+-----------+----------+
| id | perm_id | active | created | email | secret | notes | chk_sig | chk_owner | chk_time |
+----+---------+--------+---------------------+------------------+--------------------------+-------+---------+-----------+----------+
| 1 | 1 | 1 | 1970-01-01 00:00:00 | bert64@test.com | YCY7zeftvHh13s52Xs6H1w== | NULL | 0 | 0 | 0 |
+----+---------+--------+---------------------+------------------+--------------------------+-------+---------+-----------+----------+
1 row in set (0.00 sec)

mysql> select * from yubikeys;
+----+-----------+--------+---------------------+---------------------+----------+----------+--------------------------+---------+------+------+-------+
| id | client_id | active | created | accessed | tokenId | userId | secret | counter | low | high | notes |
+----+-----------+--------+---------------------+---------------------+----------+----------+--------------------------+---------+------+------+-------+
| 1 | 1 | 1 | 2007-10-03 16:11:50 | 2007-10-22 22:08:18 | YWJjZGVm | iU+jIRru | 7hX38lnjE4aW2O5MMY9NwA== | 0 | 0 | 0 | |
+----+-----------+--------+---------------------+---------------------+----------+----------+--------------------------+---------+------+------+-------+
1 row in set (0.00 sec)

mysql> select * from admin;
+----+-------+----------+--------------------------+---------------------+----------------+---------------------+--------+---------+
| id | keyid | note | pin | last_access | ip | creation | client | timeout |
+----+-------+----------+--------------------------+---------------------+----------------+---------------------+--------+---------+
| 1 | 1 | Root Key | OlEMemiArMptNPXxSlG1Nw== | 2008-08-07 21:27:51 | 192.168.200.20 | 2008-08-07 21:27:51 | 1 | 3600 |
+----+-------+----------+--------------------------+---------------------+----------------+---------------------+--------+---------+
1 row in set (0.00 sec)

which would all seem to be correct... any ideas? I've been looking at this for a few days now and am completely stumped.

Incidentally RBD, i believe you are supposed to base64 encode the aes secret key within the database, which you didn't seem to do in the posting above.
Author:  peku [ Wed Jan 14, 2009 2:46 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
I have the same problem, after reprogramming the yubikey (on Linux), ykdebug gives OK but PHP validation server says "Bad CRC". Has anyone solved this?
Author:  Simon [ Fri Jan 16, 2009 10:08 am ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
The AES key in the database appears to match. But aren't the AES keys in the database supposed to be encrypted? I recall that the validation server internally encrypts/decrypts the database contents using a static AES key. The PHP google code project doesn't seem available right now so I can't check the source, but just an idea to let you move debug things further.

/Simon
Author:  peku [ Fri Jan 16, 2009 12:36 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
I reprogrammed the yubikey with the new personalization tool for Windows using the same settings (afaik) that I used for the Linux personalization tool and now it works, so probably something I missed in the Linux version.
Author:  Erik [ Fri Jan 16, 2009 2:06 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
I have the same problem, however I do not use the php stuff, I use the wsapi.war file with tomcat, the self created key tests out fine with the sdk tool , but fails if you use the OTP server
In the documentation was mentioned the aes-field in the database is Base64 coded, is this correct ?

$ sdk/tool ecececececececececececececececec ececececececcdbtrcjudbcdukigjbvfudtifkjfrnin
warning: overlong token, ignoring prefix: ecececececec
Input:
token: cdbtrcjudbcdukigjbvfudtifkjfrnin
02 1d c0 8e 21 02 e9 75 81 f4 e2 d7 49 84 cb 7b
aeskey: ecececececececececececececececec
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
Output:
30 30 30 30 30 30 0b 00 e1 e8 ab 00 e2 94 a1 d4

Struct:
uid: 30 30 30 30 30 30
counter: 11 (0x000b)
timestamp (low): 59617 (0xe8e1)
timestamp (high): 171 (0xab)
session use: 0 (0x00)
random: 38114 (0x94e2)
crc: 54433 (0xd4a1)

Derived:
cleaned counter: 11 (0x000b)
modhex uid: ecececececec
triggered by caps lock: no
crc: F0B8
crc check: ok

http://10.x.x.x:8180/wsapi/verify?id=2& ... tifkjfrnin
h=waZsxFc9JQGqvT5i2f2c09j5F9g=
t=2009-01-16T15:02:24Z0453
status=BAD_OTP

Currently you seem to be unable to download stuff from http://code.google.com/p/yubikey-server-j/
Author:  network-marvels [ Fri Jan 16, 2009 6:40 pm ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
We would appreciate if you can provide us some logs and debugging information. This will help us to identify the exact cause and to provide a solution for it.
Author:  Erik [ Mon Jan 19, 2009 11:25 am ]
Post subject:  Re: problems with reprogrammed yubikeys: BAD_OTP
found the problem : there was a WARN in the catalina log :
2009-01-16 15:02:24,426 [http-8180-Processor24] WARN com.yubico.wsapi.Database - java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Date
and after a
mysql> update yubikeys set accessed = '1970-01-01 00:00:00';
everything worked ...

h=57IAu98PWuhub7fcowqPGWVdRis=
t=2009-01-19T12:12:45Z0343
status=OK

The error reporting could be better here, I would expect a config error message in the response from the wsapi.
Page 1 of 1 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/