Skip to content

Product key

제품 키(product key), 소프트웨어 키(software key)는 컴퓨터 프로그램을 위한 특정한 소프트웨어 기반 키이다. 프로그램의 사본이 진품임을 인증한다. 활성화는 키를 입력함으로썬 종종 오프라인에서 수행되며, 윈도우 8.1과 강튼 소프트웨어의 경우 동일 키를 사용하는 여러 사용자들을 막기 위하여 온라인 활성화가 필요하다. 모든 소프트웨어가 제품 키가 있는 것은 아닌데, 일부 배급자들은 저작권 보호를 위해 다른 방식을 사용하기도 하며, 자유-오픈 소스 소프트웨어와 같은 일부 사례에서는 저작권 보호는 사용되지 않는다.

컴퓨터 게임들은 제품 키를 사용하여 이 게임이 허가 없이 복사되지 않았음을 확인한다. 이와 비슷하게 2개의 동일한 제품 키를 동시에 사용하여 온라인 게임을 즐기는 것은 허용되지 않는다.

Categories

Product key

제품키 생성 및 관리 방법에 대한 내용.

시리얼키 선택 가이드

가장 중요한 요소는 모든 노드에 대해 고유한지 이다.

Kubernetes 에선 다음과 같은 방법을 사용한다.

MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인합니다.

  • 당신은 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 얻을 수 있습니다 ip link또는 ifconfig -a
  • product_uuid는 다음 명령을 사용하여 확인할 수 있습니다. sudo cat /sys/class/dmi/id/product_uuid

일부 가상 머신은 동일한 값을 가질 수 있지만 하드웨어 장치는 고유 한 주소를 가질 가능성이 높습니다. Kubernetes는 이러한 값을 사용하여 클러스터의 노드를 고유하게 식별합니다. 이러한 값이 각 노드에 고유하지 않으면 설치 프로세스가 실패 할 수 있습니다.

다음의 내용을 참조.

그래서 언떤거 선택?

On IDs 페이지 및 경험, 그 밖의 사이트를 참고하여 작성.

다른 사용자, 다른 세션 또는 다른 컴퓨터를 대신하여 실행되는 소프트웨어와 협력하는 소프트웨어를 프로그래밍 할 때 고유 한 식별자로 작업해야하는 경우가 많습니다. 이들은 수명뿐만 아니라 다양한 하드웨어 및 소프트웨어 개체에 바인딩 될 수 있습니다. 종종 사람들이 사용하기 위해 그러한 ID를 찾을 때 의미론과 수명 또는 ID가 명확하지 않기 때문에 잘못된 ID를 선택합니다. 다음은 Linux에서 액세스 할 수있는 약간의 이해하기 어려운 ID 목록과이를 사용하거나 사용하지 않아야하는 방법입니다.

하드웨어 ID

/sys/class/dmi/id/product_uuid
The main board product UUID, as set by the board manufacturer and encoded in the BIOS DMI information. It may be used to identify a mainboard and only the mainboard. It changes when the user replaces the main board. Also, often enough BIOS manufacturers write bogus serials into it. In addition, it is x86-specific. Access for unprivileged users is forbidden. Hence it is of little general use.
CPUID/EAX=3 CPU serial number
A CPU UUID, as set by the CPU manufacturer and encoded on the CPU chip. It may be used to identify a CPU and only a CPU. It changes when the user replaces the CPU. Also, most modern CPUs don't implement this feature anymore, and older computers tend to disable this option by default, controllable via a BIOS Setup option. In addition, it is x86-specific. Hence this too is of little general use.
/sys/class/net/*/address
One or more network MAC addresses, as set by the network adapter manufacturer and encoded on some network card EEPROM. It changes when the user replaces the network card. Since network cards are optional and there may be more than one the availability if this ID is not guaranteed and you might have more than one to choose from. On virtual machines the MAC addresses tend to be random. This too is hence of little general use.
/sys/bus/usb/devices/*/serial
Serial numbers of various USB devices, as encoded in the USB device EEPROM. Most devices don't have a serial number set, and if they have it is often bogus. If the user replaces his USB hardware or plugs it into another machine these IDs may change or appear in other machines. This hence too is of little use.

There are various other hardware IDs available, many of which you may discover via the ID_SERIAL udev property of various devices, such hard disks and similar. They all have in common that they are bound to specific (replacable) hardware, not universally available, often filled with bogus data and random in virtualized environments. Or in other words: don't use them, don't rely on them for identification, unless you really know what you are doing and in general they do not guarantee what you might hope they guarantee.

소프트웨어 ID

/proc/sys/kernel/random/boot_id
A random ID that is regenerated on each boot. As such it can be used to identify the local machine's current boot. It's universally available on any recent Linux kernel. It's a good and safe choice if you need to identify a specific boot on a specific booted kernel.
gethostname(), /proc/sys/kernel/hostname
A non-random ID configured by the administrator to identify a machine in the network. Often this is not set at all or is set to some default value such as localhost and not even unique in the local network. In addition it might change during runtime, for example because it changes based on updated DHCP information. As such it is almost entirely useless for anything but presentation to the user. It has very weak semantics and relies on correct configuration by the administrator. Don't use this to identify machines in a distributed environment. It won't work unless centrally administered, which makes it useless in a globalized, mobile world. It has no place in automatically generated filenames that shall be bound to specific hosts. Just don't use it, please. It's really not what many people think it is. gethostname() is standardized in POSIX and hence portable to other Unixes.
IP Addresses returned by SIOCGIFCONF or the respective Netlink APIs
These tend to be dynamically assigned and often enough only valid on local networks or even only the local links (i.e. 192.168.x.x style addresses, or even 169.254.x.x/IPv4LL). Unfortunately they hence have little use outside of networking.
gethostid()
Returns a supposedly unique 32-bit identifier for the current machine. The semantics of this is not clear. On most machines this simply returns a value based on a local IPv4 address. On others it is administrator controlled via the /etc/hostid file. Since the semantics of this ID are not clear and most often is just a value based on the IP address it is almost always the wrong choice to use. On top of that 32bit are not particularly a lot. On the other hand this is standardized in POSIX and hence portable to other Unixes. It's probably best to ignore this value and if people don't want to ignore it they should probably symlink /etc/hostid to /var/lib/dbus/machine-id or something similar.
/var/lib/dbus/machine-id
An ID identifying a specific Linux/Unix installation. It does not change if hardware is replaced. It is not unreliable in virtualized environments. This value has clear semantics and is considered part of the D-Bus API. It is supposedly globally unique and portable to all systems that have D-Bus. On Linux, it is universally available, given that almost all non-embedded and even a fair share of the embedded machines ship D-Bus now. This is the recommended way to identify a machine, possibly with a fallback to the host name to cover systems that still lack D-Bus. If your application links against libdbus, you may access this ID with dbus_get_local_machine_id(), if not you can read it directly from the file system.
/proc/self/sessionid
An ID identifying a specific Linux login session. This ID is maintained by the kernel and part of the auditing logic. It is uniquely assigned to each login session during a specific system boot, shared by each process of a session, even across su/sudo and cannot be changed by userspace. Unfortunately some distributions have so far failed to set things up properly for this to work (Hey, you, Ubuntu!), and this ID is always (uint32_t) -1 for them. But there's hope they get this fixed eventually. Nonetheless it is a good choice for a unique session identifier on the local machine and for the current boot. To make this ID globally unique it is best combined with /proc/sys/kernel/random/boot_id.
getuid()
An ID identifying a specific Unix/Linux user. This ID is usually automatically assigned when a user is created. It is not unique across machines and may be reassigned to a different user if the original user was deleted. As such it should be used only locally and with the limited validity in time in mind. To make this ID globally unique it is not sufficient to combine it with /var/lib/dbus/machine-id, because the same ID might be used for a different user that is created later with the same UID. Nonetheless this combination is often good enough. It is available on all POSIX systems.
ID_FS_UUID
an ID that identifies a specific file system in the udev tree. It is not always clear how these serials are generated but this tends to be available on almost all modern disk file systems. It is not available for NFS mounts or virtual file systems. Nonetheless this is often a good way to identify a file system, and in the case of the root directory even an installation. However due to the weakly defined generation semantics the D-Bus machine ID is generally preferrable.
/etc/machine-id
기본적으로 /var/lib/dbus/machine-id 에 심볼릭 링크되어있는 경우도 있다.
systemd-machine-id-setup 또는 dbus-uuidgen 을 사용하면 갱신 가능.
/etc/fstab, getfsent(), getfsfile(), /dev/disk/by-uuid, blkid
디스크 UUID

ID 생성

Linux offers a kernel interface to generate UUIDs on demand, by reading from /proc/sys/kernel/random/uuid. This is a very simple interface to generate UUIDs. That said, the logic behind UUIDs is unnecessarily complex and often it is a better choice to simply read 16 bytes or so from /dev/urandom.

시리얼키의 시간 제한(만료일)에 대한 영문 번역 및 참고자료

영문: 

TestComplete licensing modules detect changes made to the system time in order to prevent attempts to extend time-limited licenses. Therefore, it is important to ensure that the computer time and date are set correctly prior to installing TestComplete.

한글: 

TestComplete 라이센스 모듈은 시간 제한 라이센스를 연장하려는 시도를 방지하기 위해 시스템 시간 변경 사항을 감지합니다. 따라서 TestComplete를 설치하기 전에 컴퓨터 시간과 날짜가 올바르게 설정되었는지 확인하는 것이 중요합니다.

시간 변경 제한 방법 예제

  1. Windows 레지스트리 및 파일에 암호화 된 형식으로 trial_tracker 항목을 만듭니다.
  2. trial_tracker에 앱 설치 타임 스탬프 (yyyy-mm-dd-hh-mm-ss) 할당. 앱이 시작될 때마다 현재 시스템 타임 스탬프가 trial_tracker보다 크고 예상 만료 날짜보다 작은 지 확인합니다.
    • 그렇다면 trial_tracker를 현재 시스템 타임 스탬프로 업데이트하고 계속하십시오.
    • 아니요 인 경우 trial_tracker가 변조되었거나 평가판 시간이 만료 된 것입니다. 사용자에게 정식 버전을 구입하거나 종료하도록 요청하십시오.
  3. 참고: 사용자는 Windows 레지스트리 항목과 암호화 된 파일을 삭제하여이 문제를 해결할 수 있습니다 (찾을 수있는 경우). 이 경우 추가 검사를 추가 할 수 있습니다. 예를 들어 기본 레지스트리 및 암호화 된 파일의 존재를 확인하는 보조 Windows 레지스트리 항목을 만듭니다.
  4. 이와 함께 인터넷 연결에 따라 추가 원격 검사를 적용 할 수 있습니다 (선택 사항).

몇 가지 방법

PostgreSQL

마지막 통계 리셋 시간으로 시간 추적 힌트 확인. 

select stats_reset from pg_catalog.pg_stat_database where datname like 'recc';

TimescaleDB

메타정보로 설치했을 당시 UUID, 설치시간 두가지 정보 확인 가능. 

select key, value from _timescaledb_catalog.metadata;

그리고 다음 명령으로 시간 갱신을 확인할 수 있다. 

select last_start, last_finish, next_start, last_successful_finish, total_runs from _timescaledb_internal.bgw_job_stat;

c2core 에서 사용한 방법

런타임 프로그램에서 아래의 작업이 진행된다. (has public key)

  1. Keystore 저장될 디렉토리 확인 및 생성. /usr/local/c2core/var/a
  2. Keystore 파일 저장 및 열기.
  3. SessionID를 준비한다. (Keystore에 없다면 새로 생성한다.)
  4. SessionInfo를 생성한다. {SessionID, MachineID, ProductUUID}
  5. 현재시간을 확보한다.
    1. NTP를 사용한 현재시간 획득.
    2. 연결할 수 없다면 로컬 시간을 사용한다.
  6. Keystore에 저장된 CertificateInfo가 없다면 사용자 제공 파일을 확인한다.
    1. 환경변수(C2CORE_AUTH_CERT_INPUT)가 존재한다면 해당 경로의 파일이 존재하는지 확인한다.
    2. 환경변수 확인에 실패했다면 기본 경로를 확인한다. /usr/local/c2core/answer.cert
    3. 제공된 파일이 있다면 EncodedCertificateInfo 정보를 Keystore에 저장한다.
    4. 제공된 파일이 없다면 RequestInfo를 생성한후 종료한다. 이 때, 에러코드는 E_REJECTED를 사용한다.
  7. Keystore에 저장된 CertificateInfo를 확보한다.
  8. 인코딩 되어있는 CertificateInfo를 PublicKey로 디코딩한다.
  9. 인증정보가 정확한지 확인한다.
    1. SessionInfo는 완벽히 동일해야한다.
    2. 현재시간은 Deadline을 넘어선 안된다.
  10. 인증에 실패하면 사용자 제공 파일을 사용하여 확인해본다.
    1. 환경변수(C2CORE_AUTH_CERT_INPUT)가 존재한다면 해당 경로의 파일이 존재하는지 확인한다.
    2. 환경변수 확인에 실패했다면 기본 경로를 확인한다. /usr/local/c2core/answer.cert
    3. 인증정보가 정확하다면 EncodedCertificateInfo 정보를 Keystore에 저장한다.
    4. 그렇지 않다면 RequestInfo를 생성한후 종료한다. 이 때, 에러코드는 E_REJECTED를 사용한다.
  11. UpdateInfo가 존재한다면 정합성을 확인한다.
    1. Keystore의 UpdateInfo를 확보한다.
    2. CertificateInfo의 AES256{key,iv} 정보를 사용하여 UpdateInfo를 디코딩 한다.
    3. 마지막 로그인 시간보다 현재시간이 작아선 안된다. (오차율 24시간)
  12. 인증에 성공하면 UpdateInfo를 업데이트한다.
    1. CertificateInfo의 AES256{key,iv} 정보를 사용하여 UpdateInfo를 인코딩 한다.
    2. 암호화한 UpdateInfo를 Keystore에 저장한다.

인증파일 생성 프로그램에서 진행한다. (has private key)

  1. 요청파일을 읽고, Private Key를 사용한 디코딩.
  2. 인증 정보를 생성한다. {인증키, 만료시간, 서비스 제한 범위} 이다.
  3. 요청파일의 정보와 함께 인증파일을 만든다.

Fake routine

몇 분간 강제 작동시킨다.

  1. Read ethernet mac-address: MAC
  2. Encode (Static private key in original source): RSAPrivate{MAC}
  3. Save keystore file: ${STORAGE_ROOT}/key/default.key
  4. ... deploy ...
  5. Decode (Static public key in binary): MAC
  6. Test ethernet mac-address

PC ID INFORMATION:

  • Docker container: /sys/class/dmi/id/product_uuid
  • Local PC: /etc/machine-id

recc 에서 사용한 방법

Answer 실행, public-key 로 인증 요청 파일 생성. 다음 목록의 내용을 요청파일 정보에 추가.

  • 요청한 사용자 email
  • 요청한 사용자 pw (SHA256)
  • TimescaleDB UUID
  • 램덤 UUID 생성
  • 로컬 시간

인증 GUI 화면에서 인증 방법:

  • 인증서버로 요청. (인터넷 연결 가능)
  • License 파일 업로드 (인터넷 연결 불가)

인증 만료 확인 방법:

  • TimescaleDB 의 bgw(Background Worker) 마지막 실행 날짜 확인.

시리얼키 저장소

Credential Store 항목 참조.

See also

Favorite site