unique hardware identification

[Koen Martens]

Hi All,

I was wondering, if something like a unique hardware identification
would be possible on FreeBSD.

I'd like a machine to authenticate to a server, for which it will
need a unique identification. Problem is, it should be generated
automatically and not easy to fake / detect without already having
root access to the box.

I'm thinking of something like combining serial numbers from
CPU/disks for example, but there does not seem to be a clear way to
obtain these (not all cpu's even have a serial number in there).

I am just inquiring if someone on this list has an idea that might
help with this problem.

Gr,

Koen

[Devon H. O'Dell]

Post by Koen Martens
Hi All,
I was wondering, if something like a unique hardware identification
would be possible on FreeBSD.
I'd like a machine to authenticate to a server, for which it will
need a unique identification. Problem is, it should be generated
automatically and not easy to fake / detect without already having
root access to the box.
I'm thinking of something like combining serial numbers from
CPU/disks for example, but there does not seem to be a clear way to
obtain these (not all cpu's even have a serial number in there).
I am just inquiring if someone on this list has an idea that might
help with this problem.
Gr,
Koen

Hey Koen,

I know a lot of people / companies use the MAC address of a given
interface for this purpose, but it's not generally very useful since
most interfaces will allow you to set your own MAC address.

Something you could use instead is a one-wire device, attached to the
motherboard (if it has a header for it). If the motherboard does not,
you can get LCDs from e.g. CrystalFontz that provide an interface to
such devices. The Dallas one-wire thermometers have a unique 64-bit
identifier on them, however this is only really useful if you have the
ability to control the hardware platform.

If you are attempting to identify a specific hardware platform (e.g. a
standard set of motherboards and devices), you can enumerate devices
and device IDs on the PCI bus, creating some sort of hash of those.

In the end, with the client controlling the hardware, client-side
security and validation is rather difficult. Even hacking the kernel
to only run signed binaries is going to be difficult to keep secure,
even keeping the key in some hardware secured storage, shipping the
system without a debugger or symbols, and controlling the hardware.

Thank you, media, for blowing the Pentium III CPUID feature up into
something horrible. Uniquely identifiable hardware is very useful when
licensing :\.

Regarding your questions, the serial number of the hard drive is
usually not too difficult to figure out. Take a look at atacontrol(8),
for instance:

dho# atacontrol cap ad4

Protocol Serial ATA II
device model WDC WD1600JS-75NCB2
serial number WD-WCANM3753524

The serial number should be unique. camcontrol(8) can probably give
you similar information for SCSI disks.

Hope this is of some use. I'd be interested in seeing what others are doing.

Kind regards,

Devon H. O'Dell

[Bill Moran]

Post by Koen Martens
Hi All,
I was wondering, if something like a unique hardware identification
would be possible on FreeBSD.
I'd like a machine to authenticate to a server, for which it will
need a unique identification. Problem is, it should be generated
automatically and not easy to fake / detect without already having
root access to the box.
I'm thinking of something like combining serial numbers from
CPU/disks for example, but there does not seem to be a clear way to
obtain these (not all cpu's even have a serial number in there).
I am just inquiring if someone on this list has an idea that might
help with this problem.

Missed the original post on this.

Kerberos does this reliably and securely. Part of the point of Kerberos
is that machines must authenticate themselves to each other.

Another option is SSL certificates.

Although, since you don't describe the goal you're trying to accomplish,
it's difficult to know if either of those will work for you.

[Daniel Rudy]

At about the time of 12/19/2006 7:19 AM, Devon H. O'Dell stated the

Post by Devon H. O'Dell

Post by Koen Martens
Hi All,
I was wondering, if something like a unique hardware identification
would be possible on FreeBSD.
I'd like a machine to authenticate to a server, for which it will
need a unique identification. Problem is, it should be generated
automatically and not easy to fake / detect without already having
root access to the box.
I'm thinking of something like combining serial numbers from
CPU/disks for example, but there does not seem to be a clear way to
obtain these (not all cpu's even have a serial number in there).
I am just inquiring if someone on this list has an idea that might
help with this problem.
Gr,
Koen

Hey Koen,
I know a lot of people / companies use the MAC address of a given
interface for this purpose, but it's not generally very useful since
most interfaces will allow you to set your own MAC address.
Something you could use instead is a one-wire device, attached to the
motherboard (if it has a header for it). If the motherboard does not,
you can get LCDs from e.g. CrystalFontz that provide an interface to
such devices. The Dallas one-wire thermometers have a unique 64-bit
identifier on them, however this is only really useful if you have the
ability to control the hardware platform.
If you are attempting to identify a specific hardware platform (e.g. a
standard set of motherboards and devices), you can enumerate devices
and device IDs on the PCI bus, creating some sort of hash of those.
In the end, with the client controlling the hardware, client-side
security and validation is rather difficult. Even hacking the kernel
to only run signed binaries is going to be difficult to keep secure,
even keeping the key in some hardware secured storage, shipping the
system without a debugger or symbols, and controlling the hardware.
Thank you, media, for blowing the Pentium III CPUID feature up into
something horrible. Uniquely identifiable hardware is very useful when
licensing :\.
Regarding your questions, the serial number of the hard drive is
usually not too difficult to figure out. Take a look at atacontrol(8),
dho# atacontrol cap ad4
Protocol Serial ATA II
device model WDC WD1600JS-75NCB2
serial number WD-WCANM3753524
The serial number should be unique. camcontrol(8) can probably give
you similar information for SCSI disks.
Hope this is of some use. I'd be interested in seeing what others are doing.
Kind regards,
Devon H. O'Dell
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers

I've had this very question myself. Here's what I've done:

1) Use a USB Flash Drive as a hardware dongle. These devices have a
vendor id, product id, and a serial number that is garunteed to be unique.

2) Get the Link Layer Address off all the network interfaces in the system.

3) Get the model, serial, and firmware revision off the first harddrive
in the system.

4) Using the sysctl(3) interface, I found some undocumented stuff that
let's you enumerate the pnp devices in the system. Well, the kernel
tells you what they are.

[Jon Passki]

Post by Daniel Rudy
At about the time of 12/19/2006 7:19 AM, Devon H. O'Dell stated the

Post by Koen Martens
Hi All,
I was wondering, if something like a unique hardware identification
would be possible on FreeBSD.

[snip]

If the machine is a PXE-compliant device [2], it should have a GUID/
UUID [1] available. This can be exposed by sysutil/hal [3] via the
smbios.system.uuid field. The sysutil/hal port, though, requires a
decent amount of dependencies. You might want to give the pkg
install a try first. (I happened to have a lot of those ports
installed, so it was not an issue for me.)

# dbus-daemon --system
# hald --verbose=yes
16:39:24.418 [I] hald.c:469: hal 0.5.8
16:39:24.418 [I] hald.c:478: Will daemonize
16:39:24.418 [I] hald.c:479: Becoming a daemon
# hal-get-property --udi /org/freedesktop/Hal/devices/computer --key
smbios.system.uuid
64837263-8462-7493-1212-FFFFFFFFFFFF

Cheers,

Jon

[1] http://en.wikipedia.org/wiki/Globally_Unique_Identifier
[2] http://en.wikipedia.org/wiki/Preboot_Execution_Environment
[3] http://www.freshports.org/sysutils/hal/

[Peter Jeremy]

Post by Jon Passki
If the machine is a PXE-compliant device [2], it should have a GUID/
UUID [1] available. This can be exposed by sysutil/hal [3] via the
smbios.system.uuid field.

You can also get it via kenv(8) without needing any ports:
# kenv smbios.system.uuid
9F345F4F-BEFC-D431-1340-61235A56DEF9

[M. Warner Losh]

In message: <***@turion.vk2pj.dyndns.org>
Peter Jeremy <***@optushome.com.au> writes:
: On Sun, 2007-Jan-28 10:39:36 -0600, Jon Passki wrote:
: >If the machine is a PXE-compliant device [2], it should have a GUID/
: >UUID [1] available. This can be exposed by sysutil/hal [3] via the
: >smbios.system.uuid field.
:
: You can also get it via kenv(8) without needing any ports:
: # kenv smbios.system.uuid
: 9F345F4F-BEFC-D431-1340-61235A56DEF9

I wonder why the smbios stuff isn't exported via sysctls as well...

Warner

[Luigi Rizzo]

Post by M. Warner Losh
: >If the machine is a PXE-compliant device [2], it should have a GUID/
: >UUID [1] available. This can be exposed by sysutil/hal [3] via the
: >smbios.system.uuid field.
: # kenv smbios.system.uuid
: 9F345F4F-BEFC-D431-1340-61235A56DEF9
I wonder why the smbios stuff isn't exported via sysctls as well...

and this is probably a lazy vendor :)

smbios.bios.reldate="07/12/2006"
smbios.bios.vendor="American Megatrends Inc."
smbios.bios.version="P1.10"
smbios.chassis.maker="To Be Filled By O.E.M."
smbios.chassis.serial="To Be Filled By O.E.M."
smbios.chassis.tag="To Be Filled By O.E.M."
smbios.chassis.version="To Be Filled By O.E.M."
smbios.planar.maker=" "
smbios.planar.product="775i945GZ"
smbios.planar.serial=" "
smbios.planar.version=" "
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="To Be Filled By O.E.M."
smbios.system.product="775i945GZ"
smbios.system.serial="To Be Filled By O.E.M."
smbios.system.uuid="00020003-0004-0005-0006-000700080009"
smbios.system.version="To Be Filled By O.E.M."

cheers
luigi

[M. Warner Losh]

In message: <***@xorpc.icir.org>
Luigi Rizzo <***@icir.org> writes:
: On Thu, Feb 01, 2007 at 11:38:51AM -0700, M. Warner Losh wrote:
: > In message: <***@turion.vk2pj.dyndns.org>
: > Peter Jeremy <***@optushome.com.au> writes:
: > : On Sun, 2007-Jan-28 10:39:36 -0600, Jon Passki wrote:
: > : >If the machine is a PXE-compliant device [2], it should have a GUID/
: > : >UUID [1] available. This can be exposed by sysutil/hal [3] via the
: > : >smbios.system.uuid field.
: > :
: > : You can also get it via kenv(8) without needing any ports:
: > : # kenv smbios.system.uuid
: > : 9F345F4F-BEFC-D431-1340-61235A56DEF9
: >
: > I wonder why the smbios stuff isn't exported via sysctls as well...
:
: and this is probably a lazy vendor :)
:
: smbios.bios.reldate="07/12/2006"
: smbios.bios.vendor="American Megatrends Inc."
: smbios.bios.version="P1.10"
: smbios.chassis.maker="To Be Filled By O.E.M."
: smbios.chassis.serial="To Be Filled By O.E.M."
: smbios.chassis.tag="To Be Filled By O.E.M."
: smbios.chassis.version="To Be Filled By O.E.M."
: smbios.planar.maker=" "
: smbios.planar.product="775i945GZ"
: smbios.planar.serial=" "
: smbios.planar.version=" "
: smbios.socket.enabled="1"
: smbios.socket.populated="1"
: smbios.system.maker="To Be Filled By O.E.M."
: smbios.system.product="775i945GZ"
: smbios.system.serial="To Be Filled By O.E.M."
: smbios.system.uuid="00020003-0004-0005-0006-000700080009"
: smbios.system.version="To Be Filled By O.E.M."

Heh!

My comment though is why do we have to go to kenv when we could
export these via sysctl, like everything else.

Warner

[Daniel Rudy]

Post by M. Warner Losh
: > : >If the machine is a PXE-compliant device [2], it should have a GUID/
: > : >UUID [1] available. This can be exposed by sysutil/hal [3] via the
: > : >smbios.system.uuid field.
: > : # kenv smbios.system.uuid
: > : 9F345F4F-BEFC-D431-1340-61235A56DEF9
: >
: > I wonder why the smbios stuff isn't exported via sysctls as well...
: and this is probably a lazy vendor :)
: smbios.bios.reldate="07/12/2006"
: smbios.bios.vendor="American Megatrends Inc."
: smbios.bios.version="P1.10"
: smbios.chassis.maker="To Be Filled By O.E.M."
: smbios.chassis.serial="To Be Filled By O.E.M."
: smbios.chassis.tag="To Be Filled By O.E.M."
: smbios.chassis.version="To Be Filled By O.E.M."
: smbios.planar.maker=" "
: smbios.planar.product="775i945GZ"
: smbios.planar.serial=" "
: smbios.planar.version=" "
: smbios.socket.enabled="1"
: smbios.socket.populated="1"
: smbios.system.maker="To Be Filled By O.E.M."
: smbios.system.product="775i945GZ"
: smbios.system.serial="To Be Filled By O.E.M."
: smbios.system.uuid="00020003-0004-0005-0006-000700080009"
: smbios.system.version="To Be Filled By O.E.M."
Heh!
My comment though is why do we have to go to kenv when we could
export these via sysctl, like everything else.
Warner
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers

You know that's a good idea, but there is a problem with that....

None of this stuff appears on my system and I'm running 6.1. I can't
even find dmidump anywhere on the system or in ports either.

[Peter Jeremy]

Post by Daniel Rudy
None of this stuff appears on my system and I'm running 6.1. I can't
even find dmidump anywhere on the system or in ports either.

Please elaborate. kenv(8) states that it first appeared in 4.1.1 and
I don't recall seeing any reference to 'dmidump' in this thread.

If you're referring to getting smbios data reported in kenv - that is
up to your system/BIOS vendor: If they don't embed the information in
the BIOS, FreeBSD can't report it. The response on my laptop is
complete. My older whitebox desktops either don't have the data
populated or don't report it at all.

[Danny Braniss]

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Post by Daniel Rudy
None of this stuff appears on my system and I'm running 6.1. I can't
even find dmidump anywhere on the system or in ports either.

Please elaborate. kenv(8) states that it first appeared in 4.1.1 and
I don't recall seeing any reference to 'dmidump' in this thread.
If you're referring to getting smbios data reported in kenv - that is
up to your system/BIOS vendor: If they don't embed the information in
the BIOS, FreeBSD can't report it. The response on my laptop is
complete. My older whitebox desktops either don't have the data
populated or don't report it at all.

kenv appeared in 4.1, the smbios. stuff only appeared midway in 6.1

danny

[Daniel Rudy]

Post by Danny Braniss

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Post by Daniel Rudy
None of this stuff appears on my system and I'm running 6.1. I can't
even find dmidump anywhere on the system or in ports either.

Please elaborate. kenv(8) states that it first appeared in 4.1.1 and
I don't recall seeing any reference to 'dmidump' in this thread.
If you're referring to getting smbios data reported in kenv - that is
up to your system/BIOS vendor: If they don't embed the information in
the BIOS, FreeBSD can't report it. The response on my laptop is
complete. My older whitebox desktops either don't have the data
populated or don't report it at all.

kenv appeared in 4.1, the smbios. stuff only appeared midway in 6.1
danny

That would explain it then. I'm running 6.1 release with the security
updates, not stable.

[Oliver Fromme]

Post by Peter Jeremy

Post by Daniel Rudy
None of this stuff appears on my system and I'm running 6.1. I can't
even find dmidump anywhere on the system or in ports either.

Please elaborate. kenv(8) states that it first appeared in 4.1.1 and
I don't recall seeing any reference to 'dmidump' in this thread.

For retrieving DMI information, please see sysutils/dmidecode
in the ports collection. It works fine on the HP Proliant
machines here, it even reports the exact population of the
RAM slots and other things, which makes remote administration
easier.

Of course, it only works on machines with DMI-compliant BIOS
interface. If you don't get SMBIOS information, I very much
doubt that it'll provide DMI information either.

Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783
Any opinions expressed in this message are personal to the author and may
not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

"I have stopped reading Stephen King novels.
Now I just read C code instead."
-- Richard A. O'Keefe

[John Baldwin]

Post by M. Warner Losh
: > : >If the machine is a PXE-compliant device [2], it should have a GUID/
: > : >UUID [1] available. This can be exposed by sysutil/hal [3] via the
: > : >smbios.system.uuid field.
: > : # kenv smbios.system.uuid
: > : 9F345F4F-BEFC-D431-1340-61235A56DEF9
: >
: > I wonder why the smbios stuff isn't exported via sysctls as well...
: and this is probably a lazy vendor :)
: smbios.bios.reldate="07/12/2006"
: smbios.bios.vendor="American Megatrends Inc."
: smbios.bios.version="P1.10"
: smbios.chassis.maker="To Be Filled By O.E.M."
: smbios.chassis.serial="To Be Filled By O.E.M."
: smbios.chassis.tag="To Be Filled By O.E.M."
: smbios.chassis.version="To Be Filled By O.E.M."
: smbios.planar.maker=" "
: smbios.planar.product="775i945GZ"
: smbios.planar.serial=" "
: smbios.planar.version=" "
: smbios.socket.enabled="1"
: smbios.socket.populated="1"
: smbios.system.maker="To Be Filled By O.E.M."
: smbios.system.product="775i945GZ"
: smbios.system.serial="To Be Filled By O.E.M."
: smbios.system.uuid="00020003-0004-0005-0006-000700080009"
: smbios.system.version="To Be Filled By O.E.M."
Heh!
My comment though is why do we have to go to kenv when we could
export these via sysctl, like everything else.

Because the kernel doesn't expose them. This is done via /boot/loader.

[Mike Meyer]

Post by Koen Martens
Hi All,
I was wondering, if something like a unique hardware identification
would be possible on FreeBSD.
I'd like a machine to authenticate to a server, for which it will
need a unique identification. Problem is, it should be generated
automatically and not easy to fake / detect without already having
root access to the box.

At this point, you've actually described two different things:
"identifying the hardware" and "identifying to the server". The latter
just takes a string of bits that only exist in the client, like ssh
keys. Looking into something like OpenVPN's various authentication
mechanisms should give you ideas on various ways to do this.

Identifying the hardware is a bit trickier, because you have to have a
policy about what to do in the face of hardware changes, which will
influence what goes into your signature. You suggested disk serial
numbers. Does adding a disk invalidate the hardware id? Does it matter
which disk you booted from if you've got two disks in the id? Etc.

At the exterme low end, you can use an ID from something that's
trivially replacable, like an ethernet MAC. In the middle, you mix in
an id from every bit of kit that you don't want the user to be able to
change. At the extreme high end, you want to look into "Trusted
Computing", which is a technology designed to create a computer that
the content vendors will trust enough to put content on.

<mike

[s***@cydem.org]

Post by Koen Martens
I'm thinking of something like combining serial numbers from
CPU/disks for example, but there does not seem to be a clear way to
obtain these (not all cpu's even have a serial number in there).

the simplest thing that comes to my mind is parsing `dmidump` for
serial numbers, hoping there are some... (there are a few in the dump I
obtained, but it's a laptop)

[SorAlx] ridin' VN1500-B2

[Danny Braniss]

Post by s***@cydem.org

Post by Koen Martens
I'm thinking of something like combining serial numbers from
CPU/disks for example, but there does not seem to be a clear way to
obtain these (not all cpu's even have a serial number in there).

the simplest thing that comes to my mind is parsing `dmidump` for
serial numbers, hoping there are some... (there are a few in the dump I
obtained, but it's a laptop)

you can also try
kenv|grep smbios

Post by s***@cydem.org
[SorAlx] ridin' VN1500-B2
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers