AGTEK R & D Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Description =====
Internet keys are a copy protection method that allows software to be loaded on many devices but run simultaneously only up to the number of keys purchased. A company might have 10 users but only 4 keys so only 4 users could run the software at once. This is very similar to a seat license arrangement. 

The more unique part of this comes from the mobility needs of the construction industry. We need to be able to check out a seat license(key) and allow the user to keep it for a designated period of time without being connected to the internet. A typical checkout period is 3 days but this configurable by the customer representative designated as "Admin". 

Another feature that is somewhat unique to the seat license model is that we also need timers that disable the keys for non-payment. Timeout keys are those under some sort of payment plan and for initial shipment. As the end of the timeout period approaches (10 days), the software being used warns of the impending timeout on startup. Permanent keys are for situations where the user have paid in full. At that point, a designated AGTEK employee changes the key status from timeout to permanent.

One last feature that may not be unique is the capability that a key contain program enabling codes for more than one AGTEK program. This is often done to sell a program at a discount. This means that if a user checks out a key for Earthwork 3D that also contains the Materials program, no other user may use that key's Materials capability at the same time.


==== Goals ====

  * Create a common key system (copy protection) system for all current and future AGTEK products. This implies cross platform compatibility with both Windows and the Android platform for now but we should not rule out Apple OS-X and IOS.
  * Remove the single point of failures that currently exist in the AGTEK corporate hosted system. Amazon hosting is the likely answer although we should examine that configuration for any additional redundancy that it may require. It's unlikely that Amazon would go down for an extended period of time (> 1 day) but we should look at the possibility of redundant hosting in different regions or the necessity of hosting outside the U.S. for foreign sales. While this is not a rev 1 requirement, it should be understood prior to rev 1 deployment.
  * Share login authentication with AGTEK Access. It does not necessarily mean that there is only one server that does both files and keys and it is not a design requirement unless the nature of the systems. If there is a way to share authentication that would be sufficient. On the other hand, if the two functions can coexist on one system, it lowers the operational cost.
  * Create a reporting system that logs user key time and creates an audit trail that can be used for billing rental systems. Detailed, accurate reporting is a system requirement.
  * Multiple user permission levels of report viewing. For example, we need to expose to the user admin his company's current usage and amount to be billed. We need to see everyone's billing info. We will also want to expose some subset of customer's info to the sales reps (usage) but just for that rep. The report viewing can be delivered as a simple web page or an optional email (weekly and/or monthly).

==== Features ====

  * Customer can designate up to 10 users per key owned (ie; he has 3 keys, he can create 30 users)(10 users is a default number. Allow the AGTEK Administrator to change that number on a per key basis)
  * Keys (by number) are like a group. The customer's administrator can add up to 10 users to any one group.
  * Keys can have multiple program key codes assigned that correspond to what customer buys or adds on.
  * A customer may have any combination of Internet keys and AGTEK Access. One does not ensure the other. They do share a login to minimize the user interaction.
  * Allowing for rental systems. On demand systems for occasional use. Rental keys need to be flagged for special reporting.
  * Allow for a single computer system, one-time authorization mode. For example, the AGTrack product may be licensed to install on one computer system a single time. No different computer can enable authorization once it has been run once.
  * Built in Geolocation (if possible). One of the dangers of rental systems is sublet keys. Our ability to detect this is limited but there might be some sort of mild alarm possible if we see too many diverse locations appear. It's tenuous but might give some indication.
  * Announcement capability. It would be useful to have a method of passing a message to a user starting the software. For example, we had a planned maintenance scheduled but the only method of contact was email in all it's imperfection. The ability to notify users as part of the software startup could be valuable.

TBC

==== Definitions ====

These are descriptions of the keys. They may in fact be identical in the server software but have some specialized need or interface that makes them a slight variation.

=== Hasp - USB  - Hardware keys ===
These are the USB dongles, keys, etc. used by the majority of customers. They have nothing to do with the Server being defined here but are mentioned for reference.

=== Internet Keys ===
This is sort of an all inclusive key type. The other keys are variations of this. The chief characteristic of an internet key is that it connects to our internet server for an authorization. This is true for all key types illustrated below.

== Timed Keys ==
A timed key is foremost used for payment collection. In fact, all orders are shipped as timed keys initially. Upon receiving payment (or a part returned), we either make the key permanent (for a final payment) or extend the timer to the next payment required. Typically the maximum timed key is set for 12 payments max but it's not to say there haven't been longer payment cycles. 

From the user's perspective, he receives a message showing the time remaining on the key starting with 10 days remaining. This is triggered by the desktop software when it sees a time less than 10 days and requires user acknowledgment. Our days remaining have always been communicated through the desktop software only. We may want the option to email the admin at 10, 5, 2, and 1 days remaining. I don't think this would be desirable for training keys.

**Variations of timed keys**
It is possible to have a permanent key with a module that is timed. The most common situation is a user owns a permanent key and decides to purchase or demo a new module. In this case we want the module on the key to timeout while not disabling the permanent key.

== Permanent Keys ==
Permanent keys are keys that all one-time bills have been paid on. A user would never be prompted that this key would timeout in XX days. They can be disabled in the event a user stops paying the yearly subscription fee. In that case we would disable the key and send the user a usb version of his key.

== Software Keys ==
Software keys were the first implementation of the Solo server. They're a hybrid one-time authorization in that they are locked to the initial computer that is authorized but need to check in with the server once per year to continue their authorization. Their intended use is for field computers that a USB dongle hanging off would be a problem but they rarely get on to the internet. Note: if the program using a software key is started and an internet connection is found, the one year period is restarted from that date.

== One-Time Keys ==
This is a new concept for us with the intended use being low cost, more mass market products like AGTrack. Essentially it's a one time authorization on a single computer, a single time. 

== Rental Keys ==
These are very similar to timed (one year timeout period)Internet keys. Their chief difference is that we need to be able to flag transactions on these keys for billing and they will never become permanent.

== Training Keys ==
Training keys are something we use when a customer first buys a system. The idea is that a new customer wants to bring as many people up to speed and trained as possible. We might issue eight training keys on the order which would time out in 10 days. The only difference between them and timed keys is that it would be preferable if we did not have to assign users but instead made the keys available to the entire user list. We may also want to put a max time limit on them that's less than normal timed keys as a safeguard.

====The Pieces====

  * Amazon based server
  * Library/Interface for Windows MFC C++
  * Interface for Android
  * Changes to Windows client interface (Dave)
  * AGTEK Administrator's Interface (for Genny)
  * AGTEK Shipping Interface (for Glen)
  * Reporting (email,web,pdf,print) for:   
      * AGTEK Management
      * AGTEK Billing & Marketing
      * AGTEK Sales Reps
      * User admins

==== Reporting ====

Reporting is a sales and administration tool as implemented now. In the future it may become customer accessible (probably a subset through emailed reports) as well. Currently the report granularity is for a single day, updated nightly. It's accessible to AGTEK staff through web based reports tied to the AGTEK database web site. The reports we have now show:

  * Individual Key usage by Company per day
  * User hours per Company by day
  * Successful checkouts vs. failures (no key available) by Company-Key Number and the program that attempted it.

We need to add:
  * Geolocation capable based on IP address.
  * Billing reports (rentals of time with the smallest granularity of 1 day). (understanding rental versus purchase keys for segregation.) These reports need to have an audit trail like feel because we will send them as part of invoicing.


== What they are used for ==
  * Looking for usage conflicts (two people want the same key). This implies a sales opportunity.
  * Looking for non-usage. This means they're not using it and we need to make sure they don't have a problem like training.
  * Evaluating early usage. This is both to make sure that the training took and to make sure it doesn't come back. It's also a way to make sure when we give training keys (extra two week keys after install) that they are being used.
  * Some capability to verify that sublet rental activity is not taking place. Our user agreement precludes this but our means of detecting it is relatively weak. Larger companies with branches are unlikely to do it and branch use is an accepted practice. The only info we can really use is geolocation and user patterns. At best we can establish patterns of usage (users to IP, IP location) and then present changes in patterns to an AGTEK employee for further investigation. The reality is that someone doing a casual, occasional rental is not going to be easily detectable. Someone creating a business from it, should be. 


== What's missing now ==

  * Reports only show usage, not who is not using their key. Both are valuable
  * What program is being used on a key, not just the key used.
  * The ability to pass messages through to the user (Maintenance on ####, etc.)

== Inherent limitations ==

  * The checkout method over reports times used. We don't know actual time used versus time checked out. (Note: if it's desirable, we could probably log actual program usage within the desktop software and report it at the next communication. The question is whether that is desirable and what kind of disclosure we might have to make to users. In my opinion, the current level of knowledge does not require any sort of disclosure but further logging probably would. For that reason, I would not recommend deeper logging at the desktop level.)

== Needed tech ==

Checkout/Checkin must tie a checkout to a specific device for the length of the session to make it impossible to copy a checked out state to another device. The current system has vendor supplied code that samples the hardware for combinations of unique characteristics (MAC, processor ID, etc.?) to create a unique file (settings.bin) in the AGTEK folder on checkout. This file is removed on check in. Since we are moving away from this vendor, we will need a substitute. Phones could probably use MEID, etc as one of the identifiers. Concept Software used to sell a package for doing just this. It's explained here: http://www.softwarekey.com/help/plusman/concepts/enhanced_computer_id_algorithms.htm

Their approach seems pretty reasonable and in the most common cases of internet keys, the worst someone could do is check out a key, then not check it in and upgrade their system substantially (two major changes, one minor). At worst, they would not have key access for the maximum checkout period (3 days default). In those cases we would we would probably have the AGTEK Key administrator override the checkout. We use human judgement here because this should be an infrequent event and offending the user is worse than potentially giving them a system for 3 days. An abuse pattern would decrease the likelihood of us doing that again.

=== Report Examples ===
These don't show the interface for a date range. It's web based right now and uses presets like 1 day, 3 days, 1 week, etc. We'll want to vary that depending upon the report. The setting I used are generally fine for generalized knowledge. In relation to rental key reports (and maybe others), we'll want to be able to show usage by calendar month. For example, we'll bill on a monthly basis so we'd want all rentals for the month of December. The other instance is a user admin may want to see during that month how much usage they've had to date so they can estimate what their bill will be. 


== Rental Report ==
**Rental keys questions**
These are questions we need to ask sales/marketing in order to give the correct answer for billing. These are billing reports and I can imagine that we'll need several versions including details and summaries. 


**Monthly Report by Company**

{{rental_report.png?440x476}}



Total Usage Summary



== Company Hours by Key ==
{{keynumberreport.png?332x321}}

== Company Hours by User ==
This is the existing report. What's not shown that could be is which key a user used to accumulate those hours. We don't have that capability with the Solo Server.

{{keysbyuser.png?344x353}}


== Key Availability (checkout attempts vs. failures) ==
The point of this report is to see where users are failing to get keys and identify who's running their keys to capacity. It'd done with a lot of inference that a failure on checking a key out is because someone has a key. If it's possible, a better way may be to measure utilization. If a key is checked out all the time it might represent just one user that never checks it in. It doesn't tell us much in that case. A more interesting one to us for marketing is when their are multiple users and the percentage of checkout time vs. the day. It would probably use the 8 hours out of every 24 as a baseline of full utilization. This is an area that we should think about in an effort to understand usage better.

{{keyavailabilityreport.png?331x298}}

=== Logging ===

We should have some logging capability accessible for debugging. We will also want to store things like AGTEK Administrator key overrides. The issue is not trust of the AGTEK Administrator but instead gives them some record of required overrides in cases where the administrator senses abuse of the system. This gives the administrator a record of overrides for the account (The AGTEK administrator has the ability to reset a key from checked out to checked in. It's an acknowledgement that technology is not perfect and requires occasional human intervention.) 

We should also scan for true rental behaviors. One obvious one would be a frequent changing of passwords and or username and password. The question of how much of a filter (number of changes) we should use should probably be exposed to the user interface since our first attempt will be a EWAG (educated wild ass guess).



==== Security ====
While there is probably no way to stop a determined hacker, there are things we can do to make it harder and prevent any casual hacking of the key system. Not being on a common system is also a level of security in itself. The biggest threat would probably be in third world distribution. A concerted attack by multiple, skilled hackers in the third world on the desktop software is probably not preventable. The server end is much less vulnerable because it is not within a user/hacker's machine and has very limited methods of communicating with the outside world. In fact the API to manage to the server is not in the end product at all.

Some things we can do to prevent hacking and casual copying. They are:

  * Use secure sockets (SSL) for communication to and from the server.
  * Do a hash check as part of key check. This involves creating values (hash) of the release executable and storing them within that executable. Attempt to modify the exe to avoid the copy protection results in the hash not matching and results in a checkout failure. While this can be defeated if the hacker can find the value, it creates another layer of security. This check is invisible to the user but does add some minor overhead to the build process.
  * After the system is in place, look into hiring a consultant to do a security audit on the server. 


==== Failure Recovery ====

The key server is both critical yet somewhat tolerant of short downtimes. It's critical from the standpoint that it allows usage of our software. The tolerance comes a relatively low transaction rate per key. In the event of an outage, users currently in the software or with a key checked out would unaffected. The only affected users would be those trying to start the software that do not have a key checked out.

Ideally, we would have server redundancy where if a system failed, an automatic fall back to another instance would happen seamlessly from the user's point of view. 



==== Internal Support Tools ====
These are the interfaces for order entry, fulfillment, and management.


=== Order Generation and Management Interface ===

I'm imagining a Java interface to the Amazon server. We have an existing design that encapsulates the functionality needed. I'll get a copy and document the current capabilities.

**Existing Application Screen** Includes Hasp Support which we have no plans for on this server.

{{keymakeruserservice.png?504x370}}

**Functions**

  * Can override a checked out key and change it to checked in.
  * Extends timed keys upon payment receipt.
  * Extends a grace period upon request in order receive payment.
  * Changes the status of timed keys to permanent.
  * Kills keys (dum-dum te-dum dum dum da dum da dum)
  * Prints billing reports
  * Transfers keys to different companies/branches
  * Updates company names to reflect database changes (name changes)



=== Fulfillment (shipping) ===
This allows the shipping department to actually create the keys. We have and existing interface that could be copied. I'll document that as well.

**Existing Application Screen** This supports HASP keys as well and will probably be simplified for Internet Keys

{{keymakerbuild.png?504x370}}

**Functions**

  * Creates new keys
  * Adds programs to existing keys 



==== Programmatic interfaces ====

This should be a multiple platform solution. At minimum, we'll need an C++ API for Windows and a Java equivalent. Ideally the windows API would be compatible with VS 6.0 but that might not be possible. VS 2005 is the next stopping point. We are not currently using .Net at all. This will need further research on all the platforms we are developing on. 

==== User Interfaces ====

The Android key interface is defined in the SmartDirt project. This section describes the interface and flow for the desktop projects. This is derivative of the existing interface to minimize retraining and new documentation. By defining it here we also expose some of the elements needed to be transmitted and stored.

A typical user flow is:

  * Program is started and hardware key is looked for. If not found, the user is asked if they wish to try an Internet key.
  * The login window displays and attempts authentication when Ok is pressed. 
  * Based on the user login, the keys available (the user is on that key) show on the Keys Available tab.
  * Selecting a key and pressing Ok checks that key out from the server for a maximum amount of the Checkout period (specified on User Admin screen, default is 3 days).
  * On exit from the program, the user is given the option of checking the key back in. 
  
Atypical user flow:

  * If no keys are available to a user logging in, the keys available screen is blank. He can check the In Use tab to see all of the companies keys that are in use.

=== Windows Interface ===
This is derived from our current interface to the Solo key server. I've customized the screens below to reflect the changed needs (user associated with keys). I'll try to call out the differences from the existing users next to screen.

== Login ==
This is unchanged from current desktop apps.

{{dtlogin.png|}}

== Keys Available ==
After login, this is the first screen shown to the user. This differs from the existing Solo server in several ways.

  * The Users button is new and only displays for those users having admin privileges. It is only active when a key is selected.
  * Removed the Internet Admin tab. It contained only one control (Checkout time limit) and that is easily placed on the User Admin tab.
  * Non-Admins do not see the Users button or the User Admin tab at all
  * Users only see keys available that they have authorization to use.


{{dtavailable2.png|}}


**User Key assignment**
This is a new admin screen for assigning users to key. It's accessed by selecting a key and pressing the User button. It displays all the users for a company, sorted first by users with the key enable, and alphabetically on the user login. This means it's easy for an admin to see who's on a key at the top of the list but find users that aren't enabled more easily in list below. 

{{dtuserkey1.png|}}

== Keys in Use ==
{{dtinuse.png|}}

== User Admin ==
{{dtuseradmin1.png|}}
{{dtuseradminmenu1.png|}}
AGTEK R & D Wiki

User Tools

Site Tools

Page Tools
