Desktop

1. Add Export - Sitework 3D compatible file function instead of using IP Grid Compatible
2. Check for Update to be run on program start - also user command on Help - Check for Updates
   1. Requires checking with server for version
   2. Download of server provided link
   3. Closing of the program, checkin of the key, and running of provided installer
3. Updated fingerprinter provided (MA)
   1. Remove Mac Address from use
   2. Does the following link reference also generate a unique ID Unique ID? We no longer need to support Windows XP. Vista is a question but not a big one. Or is this also Machine ID ( I don't think so).
   3. Add physical hard drive serial# Code example?
   4. Require Machine ID on start and heavily weight. Does Machine ID have an issue with 32 bit Tony Reynolds 32bit comment
   5. Decrease weight of userlogin for addition but cause negative points for difference (does it nuke now?)
   6. Up weight of machine name and cause negative points for different machine name
   7. Lower BIOS version weight and remove memory points if bios version changes
   8. Verify OS version code because of visible differences (not sure of check method. Windows class Here) Question of whether the current version handles 32 bit correctly Here and Here
4. Detect checked out keys on install and prompt/or do checkin before install. Clean Bin files.
5. Remove the ability to run more than one session
6. Fix Bug #810 where existing process with stale key causes key lockup when new process with new key is started
7. Move and obfuscate bin files from c:\AGTEK to a more user specific location
8. Adding a randomized non-ui thread time check to the software independent of the mode switching.This requires a different server call when internet connectivity exists that checks the key status uniquely and provides the server with the next random time value. Rechecks before expected will be flagged and logged for future reports
9. Perform routine maintenance of bin files to prevent stale values from long past checkouts from causing fingerprint mismatches.
10. Store passwords only as tokens instead of encrypted text. This is a security problem bigger than us.

Server

Task list, including FingerPrinter: LicenseKey refactor tasks 2018

1. Server planning for rejection of of designated older versions. Faculty to designate said versions and tracking
2. Setting up limited Company with limited user access to files for all versions. Currently we store under Current Versions of the AGTEK Corporate Company (MC)
3. Creation of a Web Update page to be used for this campaign with clear messaging and direct links to versions both 64 bit and 32 bit. Not behind Firewall but set to not web index or link directly to the site.(MC)
4. Creation of a check key status (verify? name?) for use by the desktop code to verify the current key status at a random range and generate back to desktop when the next check time will be. This is distinguished from other calls in order to log possible dual use of keys. Server will at this time just log situations where the same key number is checking in too early. The absence of a checkin would not constitute a log situation necessarily as the user could have closed the program but retained the key. Make the bounds configurable from the server.
5. Add support for messaging with links, basic html.
6. Add support for specific to the user messaging. In the future the baked in ability for the server to respond with a message to a specific user based upon something they've done or not done (update your version for example).
7. Add total checkouts for report period to reset report to give problem context.

Check Web and mobile for compatibility.

Versions that will be updated

Will ask again for clarity on GradeModel and Materials 3D. At this point I'm saying no.

The New Version column may be redundant since it pretty much matches the cutoff version

Cutoff date at this point is set for November 13th.

1. Adjustments based on Revision 1 experience
2. Tells and other information based on Citrix experience
3. Process limiting?
4. Monitoring of older versions being used and later rejected.

1. Version - soft release web & new versions
2. Registered Letter - 9th
3. Email - October 22nd
4. Message
5. Server version Monitoring for older versions - method of reporting/notifications
6. Cutoff
7. Messaging

Proposed Steps/Features of Key Revision ( Sitework, Materials, Trackwork, any others?)

• Dispersion and obfuscation of bin files users to user-specific location and/or multiple locations to make it more difficult to duplicate easily through backup or other means. (There is no legitimate reason for a user to copy these)
• Application Update reminder and messaging system (Application and server pieces tbd)
• Improvements to key check-in and verification
• Fix Bug #810 http://dev.agtek.com:12345/jtrac/app/item/SITEWORK4D-810 which is related to housekeeping of keys.
• Fingerprinter refinement (removing, adding, weights, behaviour)
• Tracking program active vs key retained
• Limiting Sessions to one and behavior when detected
• Limiting number of processes (# allowed)
• Server Settings to reject versions older than ### of Desktop software. Implementation and user Messaging

The current versions store their files in \AGTEK along with other individualized AGTEK data like Materials and Structure lists. This is asking for an inadvertent or purposeful backup of bin files with checked out keys that will cause problems.

We apparently also don't do any cleaning of Bin files which have slots for multiple key opens and old stale settings may persist.

With few exception (Hasp), 4D key users are all required to have technical support and should have access to software updates. The android software (non play store) has the ability for us to push an update and notify the user. It's not possible to force the install but yo can remind them whenever the software starts.

My guess is we can use part of the server system for that side of the process. On the desktop side we'd have to create the method, be able to run it separately from the desktop code so that code can be shut down for updating.

We have some messaging built into the server now. It was primarily designed to announce Server maintenance. A suggestion is to add more capability like links.

We currently mainly check at startup and mode start. This is a legacy of hardware keys, single processes, and non-internet connected computers. We don't intend to disallow non-connected computers but most are connected. We need to check more often just a mode switch and should introduce a timed check of connection and then check of the key. This should not be on the UI thread as to not cause interruption to work and it can't be so often as to cause server loading issues. A possible other use for this is if we use a timed connection then it might be a tell of more than one key usage on different machines. If a test checked every 22 minutes and then a machine checked in five minutes later then that could be an indication of two separate machines. This checkin would need to be distinguishable from a normal checkin/checkout(Something we monitor only at first).

We also need to connect and leave a marker when the user exits software but retains the key.

Some of the anomalies showing up with logging show a need to refine the fingerprinter. These refinements include review of the weighting, removing some items like Mac Addresses and counts, looking for other markers, and checking the quality of the values we're seeing

Potential methods to identify key scofflaws Use set key timer checks (connected) to verify whether more than one key is in use and notify us of that case.

?Use computer name in key checks with server?

Fix Log issues on Fingerprinter

Register when the software is checking in a key for a fingerprinter violation

Set time checks to identify usage more often the

Keeping Key message - Exit from software.

Require that the computer get a machine ID to run

Version requires key to be checked in before install (no support of existing BIN files)

2018-09-19

This note describes reccomendations for changes to the management of LicenseKeys on desktop (Windows) applications.

Issues we've seen:

• False finger print failures due to mismatch of component values
• High variability of MacAddresses
• Unreliability MacAddresses (can be created from “whole cloth”, duplicates from VMs, etc)
• Uniformity of CPUs in modern systems
• Users running with keys from other machines
• Seemingly random local resets due to other errors

Goals:

• Remove erroneous or useless finger print state variables.
• Improve unique machine restriction on Licenses with reexamining weighting.

Reccomendations:

• Produce an unambiguous written document stating the behavior of LicenseKeys
• Remove MacAddress state variables from finger printer
• Remove Multiple CPU state variables from fingerprinter (ie: Intel(R) Core(TM) i7-6600U CPU @)
• Move stored file from C:\Agtek (or user specified directory) to a known machine specific location
• Encrypt stored key files with CPU unique key (e.. Machine_ID) [this is a minimal recommendation]
• Encrypt stored key files with CPU & user specific key [this is more recommended than last]
• Examine Windows for other unique state variables that can be added
• Run Mike A's multi machine finger print tester process after implementing the above.

Implications:

• With fewer state variables to fingerprint, the printer is more susceptible to false positives.
• Using machine unique (or better machine+user) encryption keys, the finger printer will not present false positives
• What happens if for some reason Machine ID is not present (Does Vista support it, New OS, different scheme) Does the fingerprinter limp along if not present? Machine ID appears to be a Microsoft generated value/dependency

2018-09-19 Weights

Notes about compare:

• Failure of MachineID to compare will always cause a key failure.
• Licenses compare the saved (old) FP with a “current” FP
  • A value in “old”, but not in “current” will compare old value with an empty string “”.
• Required sum must be >= 20
• Currently two CPU descriptions and two MAC addresses are used.
• Might consider adding hard drive serial, it's not there now.
• Motherboard serial is not used, as it's not reliable (not all boards have them, or are manufacturer specific). For instance Dell refers to them as service tags, HP does something different.

Characterizing fingerprint values - Specific vs Unique Values

Part of the weighting strategy has to take into account the characteristics of values being compared.

Original Spreadsheet with scenarios here:

fingerprinting_values_and_scenarios.xlsx

fingerprinting_values_and_scenarios_-_finger_print_model.pdf

New concept is negative weights. Removed User ID because it isn't always available when the fingerprinter is run and could cause issues by not being available. Since the fingerprinter is really about identifying the machine not the user, it should not be part of the fingerprinter code. Instead it should be used with the time check and verify if used at all. Decisions on whether to make a username mismatch a problem for the user still needs to be decided but it is not part of the fingerprinter.