Understanding how Emby Licensing works Offline

[Mikoyan 15]

Hello again.

Had the local internet go down which was annoying, but then I noticed that I could not stream from a few of my devices from my local emby instance due to "not having premiere", which was tenfold more annoying. It is my understanding that there is a period where the license is cached (for at least 3 weeks? Unclear on this part) and devices should not require additional subscriptions or etc. to use Emby from devices so long as it conforms  to the device limit. However, certain devices such as my iPad refused to stream from the server despite only losing internet a few hours prior due to no subscription.

What I want to understand:

- Does emby cache licenses on a per-device basis? Do all of these separate devices need internet beforehand to 'authenticate'?

- Why did my device(s) ask me for a subscription when the server clearly had an active key mere hours ago? (less than 3) Possibly indicating the server does not provision premiere from itself to devices.

- Why doesn't Emby Server recognize the loss of internet and cache the license on the server proper, removing the need for each device to ask me if I have a subscription or not? I don't have the option of entering a key on the device(s) so I was stuck on some devices unable to use Emby.

- How do these "grace periods" work? It should technically only start counting from the time the server detects an extended loss of connection (maybe 30min) no? Need finer understanding.

I already skimmed similar threads and understand Emby needs a semi-periodical check to validate the key, which is fine and not the topic of this question - What I want is to have a hassle-free experience in between those checks when someone sticks a shovel into the fiberbox by accident and I have to go over a day without internet. Thats the biggest appeal of this software for me, being able to keep my media local.

 

Not sure if this is the correct location for this post, please move if needed.

[Q-Droid 989]

I think this should be moved to the Emby Server - General sub-forum since it's a universal problem that affects all platforms and you'll have more participation in that section.

 

[Junglejim 385]

Emby as you've learnt will periodically need the internet, it could just be unlucky that your outage came about at the wrong time for the server. As far as apps, I think they just look at the server for the access rights..?  unless you maybe paid just for the app unlock through the store (android tv, etc.)??

Edited May 31, 2024 by Junglejim

[ebr 16169]

Hi.  The devices all validate directly.  The apps should cache successful validations for at least 24 hours and probably a few days.  However, there would have to be a successful validation within that period.

IOW - if you picked up your iPad for the first time in a week right after the outage, then it is not going to have any cached validation.

[Neminem 1518]

3 hours ago, ebr said:

The apps should cache successful validations for at least 24 hours and probably a few days.

See in red.

What ?? don't you know?

is it ?

or is it not?

Edited May 31, 2024 by jaycedk

[ebr 16169]

33 minutes ago, jaycedk said:

See in red.

What ?? don't you know?

is it ?

or is it not?

How long it is cached is actually variable depending on some factors but it is generally a week.

[Neminem 1518]

5 minutes ago, ebr said:

some factors

Hmm inlighten me, that's very vague.

You should be a politician. 

Edited May 31, 2024 by jaycedk
Spelling

[Q-Droid 989]

6 hours ago, ebr said:

Hi.  The devices all validate directly.  The apps should cache successful validations for at least 24 hours and probably a few days.  However, there would have to be a successful validation within that period.

IOW - if you picked up your iPad for the first time in a week right after the outage, then it is not going to have any cached validation.

Maybe it's time you guys overhaul this licensing enforcement mechanism and let the servers manage it when internet connectivity is lost.

 

[ebr 16169]

48 minutes ago, Q-Droid said:

Maybe it's time you guys overhaul this licensing enforcement mechanism and let the servers manage it when internet connectivity is lost.

 

You mean make it super easy to defeat?

[richt 94]

52 minutes ago, Q-Droid said:

Maybe it's time you guys overhaul this licensing enforcement mechanism and let the servers manage it when internet connectivity is lost.

 

YES!!!!  - Because when Internet connectivity is lost, it is very likely that the NUMBER of clients becomes severely limited and unlikely to even come close to an excessive number connections.  Please re-think this as I am sure there is a better way to fulfill your requirements AND make our lives easier during an outage.

[Mikoyan 15]

7 hours ago, ebr said:

The devices all validate directly

Why this choice? Would it not make more sense to have the server centrally manage the license since it is the one with the key? Similar to how Windows Server operates when hosting Windows VMs

3 hours ago, ebr said:

How long it is cached is actually variable depending on some factors

What kind of factors?

 

4 minutes ago, ebr said:

You mean make it super easy to defeat?

Well no, obviously not (why this kind of response?). But at a minimum make it more clear and straightforward. The premiere license should cover all devices upto the device limit, and start counting the offline period from shortly after outage as I have explained. Maybe add a way to manually enter the key on the client side so server side can confirm device and actually let me use it? I nor anyone else should have to rotate all of my devices every week to take advantage of premiere during the arguably *most important time when needed*. You could use dynamic keying to have clients counted on server side and only server keeps track of outage. The actual implementation will clearly be up to Emby team, I am just making quick suggestions. But as is, it is very inconvenient and frankly makes very little practical sense from the end user standpoint.

[ebr 16169]

Again, all of those suggestions just make it even easier to defeat both the registration requirement and the limits.  Might there be some way with a lot of effort and possible more defeat points to make it work differently - sure.  But this should be an extremely rare situation in today's world and we feel our development, testing and maintenance time are better spent elsewhere.

A lot of our features are free and we still have people stealing on a daily basis.  We simply have to protect our product in some ways and allocate our limited resources where have the most benefit.

[Q-Droid 989]

24 minutes ago, ebr said:

You mean make it super easy to defeat?

No. Why is that your main concern instead of trying to make Emby more usable and flexible under these circumstances? Making it hard to circumvent is part of the problem but starting from a place that it needs to be impossible to defeat is the wrong approach.

[darkassassin07 652]

29 minutes ago, Mikoyan said:

Why this choice? Would it not make more sense to have the server centrally manage the license since it is the one with the key? Similar to how Windows Server operates when hosting Windows VMs.

 

If the clients only ever check in with your server; you can modify the responses your server sends, allowing any client to bypass the requirement for premier. This would be trivial, requiring only a reverse proxy.

 

[Mikoyan 15]

37 minutes ago, darkassassin07 said:

 

If the clients only ever check in with your server; you can modify the responses your server sends, allowing any client to bypass the requirement for premier. This would be trivial, requiring only a reverse proxy.

 

I did a small amount of thinking and wanted to try and answer this hypothetical even if it deviates from my original post a bit. Feel free to correct me if anything I wrote is inaccurate (it might be because I wrote this in kind of a hurry)

If Emby client and server applications shipped with an embedded CA that is signed by the master licensing server with a very private key (not the user server), and required a valid timestamped certificate (grace period being "it's been less than x weeks since expiration") provided by said master server while the end user server was still online to enable Premiere, you would not need any form of communication between the licensing authority itself, only need a properly signed and encrypted certificate that can be verified by the CA (which is locally installed), which emby server/clients will automatically reject after the certificate expires and a certain amount of time has passed (grace period).

This would obviously require that the CA be updated on a semi-regular basis to prevent old CAs from being used (once a year?) but you could just package it in with each major update (which generally, happens once a year, and you would have to anyway for smart device apps). The amount of time and effort required to compromise the private key on the master licensing server or brute force it would be much more significant than simply cracking the APK or etc. so I would not consider it "trivial".

"But what if users change the system time to prevent the certificate from expiring?" -> you can already do this with current implementation to trick the local emby server into thinking it has not passed a lot of time since it went offline/whatever mechanism is in place to prevent such attacks can just be re-used to ensure certificate/license cannot be used after the grace period ends. Not only that but you would have to continually change system time/forever keep the server offline which I think is a lot of work that most people won't go through with.. It will eventually have to connect to the internet for whatever reason. You could also compare with the connecting device(s) time, and especially if its a modern phone it will have access to GPS time which is generally accurate.

So no, I think it is not as trivial as modifying responses (unless they're unencrypted in which case why bother with licensing at all?). If that were true for most protocols, the interweb would be a much unsafer place.

[Q-Droid 989]

I agree. There are ways to protect the data stored and in transit and ways to verify the integrity of the data to detect tampering. It's a matter of coming up with a solution that can work with or extend the current scheme. And in my view the purpose is for a backup when the licensing service is not reachable so limits would be expected and baked in. Once the server can connect to the license service it can synchronize and reconcile to re-level the usage and correct discrepancies.

 

 

Edited May 31, 2024 by Q-Droid

[pwhodges 2012]

If you use the same key on multiple servers (perfectly valid), they would all have to interconnect for "local" verification; having it done centrally by Emby is in effect a form of that interconnection and avoids connection counts being run up on multiple servers.

Paul

[Q-Droid 989]

@ebr Regarding this licensing and device limits and based on your insider knowledge how aggressive and sophisticated would you say are those who try to defeat the system? Honest question, not trying to imply anything.

 

[ebr 16169]

28 minutes ago, Q-Droid said:

@ebr Regarding this licensing and device limits and based on your insider knowledge how aggressive and sophisticated would you say are those who try to defeat the system? Honest question, not trying to imply anything.

 

Sophisticated enough.

I'll point this out again:

15 hours ago, ebr said:

Might there be some way with a lot of effort and possible more defeat points to make it work differently - sure.  But this should be an extremely rare situation in today's world and we feel our development, testing and maintenance time are better spent elsewhere.

 

[Dreakon13 143]

Only vaguely related but wanted to drop my thoughts here...

I wish hardware transcoding weren't a Premiere feature.  Love Emby, don't mind paying to support the cause, debating buying more lifetime keys for the hell of it.  But hardware transcoding is such a key feature for regular use with widely variable device compatibilities and potential bandwidth limits/connectivity issues... especially considering the hardware is just sitting there next to it waiting to be used, doesn't otherwise require external connections, having it locked behind a (mostly) persistent internet connection/paywall hurts a little bit.  It's the one feature that, in my eyes, takes it from a truly personal media server to that machine that needs to be connected to Emby's servers most of the time.

It's probably the main reason people pay up so I can't imagine it would ever change but if I had one wish. 

[justinrh 260]

On 5/31/2024 at 8:12 AM, ebr said:

IOW - if you picked up your iPad for the first time in a week right after the outage, then it is not going to have any cached validation.

I'm really ignorant of most of this, but I'd think the only caching needs to be on the server.  If the server's cache is good, then any client would be good.  Or is what you mentioned for a paid client app and not an Premiere server license?

[darkassassin07 652]

Part of the trouble with having your server handle device counts is premier keys are not limited to a single server.

It's not 25 devices per server, it's 25 devices total per key, which can be installed in as many servers as you'd like.

If your local emby servers are the ones keeping track; you could setup a dozen instances all using the same key, take them offline and suddenly you've got 12x25=300 premier devices for 2 weeks until they demand online refreshing. (well, less, as the servers take up a device slot too; but you get the point)

[Q-Droid 989]

24 minutes ago, darkassassin07 said:

Part of the trouble with having your server handle device counts is premier keys are not limited to a single server.

It's not 25 devices per server, it's 25 devices total per key, which can be installed in as many servers as you'd like.

If your local emby servers are the ones keeping track; you could setup a dozen instances all using the same key, take them offline and suddenly you've got 12x25=300 premier devices for 2 weeks until they demand online refreshing. (well, less, as the servers take up a device slot too; but you get the point)

That is understood and is part of the challenge. In the grand scheme of things an offline server is pretty useless except to those in the immediate vicinity. So setup a dozen instances, take them offline then what, 300-ish slots available for nobody to use? Sure, there are ways to make these enclaves work and one of the factors to consider is how difficult might that be for the hosting side and the client side. The harder it gets then fewer will use it.

What makes this interesting to me is devising a way to accommodate these scenarios and try to foresee how others would try to defeat it. For me this is a mental exercise, a puzzle to work on.

 

[darkassassin07 652]

I should have been more clear: 'Offline' in this case just means can't connect to embys public validation servers.

This could be just a firewall; still allowing online clients to connect to the servers.

 

Grab 2 keys, switch which key the servers use every 2 weeks, and only allow them to connect to the validation servers once every key swap.

Unlimited devices. (depending on the number of server instances you decide to run)

[Q-Droid 989]

I understood what you meant.